The XML Files: - CiteSeerX

ibm.com/redbooks

The XML Files:Using XML for Business-to-Businessand Business-to-Consumer Applications

Luis EnnserPietro Leo

Tamas MeszarosEric Valade

XML in IBM’s Application Framework for e-business

Patterns for B2B and B2C Applications

Learn about TPA-Trading Partner Agreements

http://www.redbooks.ibm.com/



September 2000

SG24-6104-00

International Technical Support Organization

© Copyright International Business Machines Corporation 2000. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (September 2000)

This edition does not apply to any specific operating system or application other than those describedwithin this document.

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. QXXE Building 80-E2650 Harry RoadSan Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix C, “Special notices” on page 297.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Part 1. Introduction to e-business and XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. XML and e-business applications . . . . . . . . . . . . . . . . . . . . . 31.1 About e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Business transformation and innovation . . . . . . . . . . . . . . . . . . . . 51.1.2 Which is the e-business value? . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3 A simplified classification schema for e-business applications . . . 8

1.2 The Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . . . . 151.2.1 World Wide Web document standards . . . . . . . . . . . . . . . . . . . . 161.2.2 A brief history of XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.3 XML — a universal data format . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.4 A short comparison of XML and HTML . . . . . . . . . . . . . . . . . . . . 191.2.5 XML linking and addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.6 Advanced type definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2.7 Metadata (RDF and PICS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2.8 Domain-specific document definitions. . . . . . . . . . . . . . . . . . . . . 221.2.9 XML in wireless applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2.10 XML styling and transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.2.11 XML query languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2.12 Processing XML documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2.13 Organizations concerned with XML. . . . . . . . . . . . . . . . . . . . . . 291.2.14 Typical applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.3 XML and e-business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 2. Introduction to IBM e-business solutions. . . . . . . . . . . . . . 352.1 IBM e-business cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2 IBM Application Framework for e-business. . . . . . . . . . . . . . . . . . . . . 37

2.2.1 Using an asset-based approach . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.2 Overview of the IBM Application Framework. . . . . . . . . . . . . . . . 422.2.3 Patterns for e-business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

© Copyright IBM Corp. 2000 iii

Chapter 3. XML in the IBM Application Framework for e-business . . . 593.1 e-business application with XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2 IBM XML development tools and utilities . . . . . . . . . . . . . . . . . . . . . . 63

3.2.1 Open source initiative: the xml.apache.org project . . . . . . . . . . . 653.2.2 Parsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.2.3 Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.2.4 Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.2.5 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.3 XML open frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3.1 OASIS consortium, XML.ORG . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3.2 Electronic Business XML initiative (ebXML) . . . . . . . . . . . . . . . . 843.3.3 WebSphere B2B Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.4 XML extensions to IBM products . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.4.1 WebSphere Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . 893.4.2 VisualAge for Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963.4.3 MQSeries Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.4.4 DB2 XML Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.4.5 Lotus with XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.4.6 Tivoli Cross-Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Part 2. Designing B2C and B2B e-business applications using XML . . . . . . . . . . . . 105

Chapter 4. Patterns for B2C and B2B applications . . . . . . . . . . . . . . 1074.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.1.1 Logical and physical patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.1.2 Runtime topology nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.2 e-business patterns for B2C applications . . . . . . . . . . . . . . . . . . . . . 1104.2.1 B2C logical patterns for e-business . . . . . . . . . . . . . . . . . . . . . 111

4.3 e-business patterns for B2B applications . . . . . . . . . . . . . . . . . . . . . 1174.3.1 B2B logical patterns for e-business . . . . . . . . . . . . . . . . . . . . . 1174.3.2 Physical patterns for B2C and B2B runtime topologies . . . . . . . 127

4.4 Implementation considerations for XML . . . . . . . . . . . . . . . . . . . . . . 1294.4.1 Applications that benefit from using XML . . . . . . . . . . . . . . . . . 1304.4.2 Typical design for applications using XML . . . . . . . . . . . . . . . . 1314.4.3 A sample of an architecture for XML applications . . . . . . . . . . . 1324.4.4 Composing Java object with XML . . . . . . . . . . . . . . . . . . . . . . . 1354.4.5 XML filtering with Java servlets . . . . . . . . . . . . . . . . . . . . . . . . 1354.4.6 XML/XSL as inputs for a Web application generator . . . . . . . . . 1364.4.7 Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364.4.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

iv The XML Files: Using XML for B2B and B2C Applications

Chapter 5. B2C applications using XML . . . . . . . . . . . . . . . . . . . . . . . 1395.1 The B2C application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.1.1 The field of business-customer interaction . . . . . . . . . . . . . . . . 1395.1.2 Application models, architectures and components . . . . . . . . . 1405.1.3 XML powers the B2C interaction. . . . . . . . . . . . . . . . . . . . . . . . 143

5.2 Enterprise portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445.2.1 Data and application integration . . . . . . . . . . . . . . . . . . . . . . . . 1465.2.2 Content management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485.2.3 Controlled access to structured information . . . . . . . . . . . . . . . 1515.2.4 Customer relations, recognition, and personalization . . . . . . . . 1525.2.5 Business intelligence and enterprise portals . . . . . . . . . . . . . . . 1565.2.6 Connection to e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575.2.7 New presentation devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605.2.8 IBM portal examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

5.3 IBM products and tools in B2C applications . . . . . . . . . . . . . . . . . . . 1655.3.1 Enterprise Information Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 1665.3.2 Lotus Raven suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.3.3 IBM WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715.3.4 IBM products and tools in portals . . . . . . . . . . . . . . . . . . . . . . . 174

5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Chapter 6. B2B applications using XML . . . . . . . . . . . . . . . . . . . . . . . 1776.1 The B2B application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.1.1 B2B: a major business opportunity of business integration . . . . 1776.1.2 General issues in business-to-business electronic interactions. 1796.1.3 XML B2B frameworks and standards . . . . . . . . . . . . . . . . . . . . 180

6.2 IBM WebSphere B2B Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846.2.1 Trading Partner Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.2.2 The IBM Business-to-business Protocol Framework . . . . . . . . . 2046.2.3 A sample application TPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126.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 . . . . . . . . . . . . . . . . . . 2417.1 Why the B2B eMarketPlace application? . . . . . . . . . . . . . . . . . . . . . 2417.2 eMarketPlaces and online intermediaries . . . . . . . . . . . . . . . . . . . . . 242

7.2.1 B2B online intermediary business trading models . . . . . . . . . . . 2447.3 The E-broker application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

7.3.1 E-broker business models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2477.3.2 Considerations on the impact of XML on the architecture . . . . . 2577.3.3 A building block architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

v

7.3.4 E-broker application functional decomposition . . . . . . . . . . . . . 2647.4 Initial E-broker design activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

7.4.1 E-broker access service TPAs . . . . . . . . . . . . . . . . . . . . . . . . . 2727.4.2 The directory service data model in DB2 XML Extender . . . . . . 274

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Appendix A. An example of a OBI TPA XML document . . . . . . . . . . . . 281A.1 The OBI TPA between Large Co and Pens We Are . . . . . . . . . . . . . . . . 281

Appendix B. Using the additional material . . . . . . . . . . . . . . . . . . . . . . 295B.1 Locating the additional material on the Internet . . . . . . . . . . . . . . . . . . . 295B.2 Using the Web material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

B.2.1 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

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

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

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

vi The XML Files: Using XML for B2B and B2C Applications

Figures

1. The e-business adoption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62. The e-business applications classification schema . . . . . . . . . . . . . . . . . . . 93. Growth of the business-to-consumer sector . . . . . . . . . . . . . . . . . . . . . . . 124. Growth of the business-to-business sector . . . . . . . . . . . . . . . . . . . . . . . . 145. XML supports a number of other languages . . . . . . . . . . . . . . . . . . . . . . . 206. SAX application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277. DOM interface hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288. IBM e-business cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369. Three-tier computing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310. Application Framework for e-business architecture . . . . . . . . . . . . . . . . . . 4411. WEB application topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5012. Using Application Framework for e-business: a simple approach . . . . . . . 5213. Leveraging the IBM Application Framework for e-business with XML. . . . 6014. XML in a Web application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 6115. IBM XML components in the e-business application architecture . . . . . . . 6316. BPF as a business-to-business coordinator . . . . . . . . . . . . . . . . . . . . . . . 8817. DB2 XML Extender overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9818. Lotus Domino XML language opens Domino data . . . . . . . . . . . . . . . . . 10119. Tivoli Cross-Site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10320. Application topology: Web-up topology 1. . . . . . . . . . . . . . . . . . . . . . . . . 11221. Runtime topology: Web-up topology 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 11322. Application topology: Web-up topology 2. . . . . . . . . . . . . . . . . . . . . . . . . 11423. Runtime topology: Web-up topology 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 11524. Application topology: document exchange . . . . . . . . . . . . . . . . . . . . . . . 11825. Runtime topology: VAN-document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11926. Application topology: Direct exchange with adapter/bridge . . . . . . . . . . . 12027. Runtime topology: Internet direct queue . . . . . . . . . . . . . . . . . . . . . . . . . 12028. Application topology: message broker . . . . . . . . . . . . . . . . . . . . . . . . . . . 12129. Runtime topology: Internet brokered . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12230. Application topology: business protocol managed. . . . . . . . . . . . . . . . . . 12331. Runtime topology: Internet managed. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12432. Application topology: jointly managed . . . . . . . . . . . . . . . . . . . . . . . . . . . 12633. Runtime topology: Internet jointly managed. . . . . . . . . . . . . . . . . . . . . . . 12734. Typical design for a Web application with XML . . . . . . . . . . . . . . . . . . . . 13235. Architecture of XML application with Cocoon . . . . . . . . . . . . . . . . . . . . . 13436. The main areas of business-to-customer systems . . . . . . . . . . . . . . . . . 14137. Interfaces between the main areas of B2C systems . . . . . . . . . . . . . . . . 14238. Enterprise portals connect data, applications and people together . . . . . 14539. Integrating clients, applications, and portals . . . . . . . . . . . . . . . . . . . . . . 14740. Content management general architecture . . . . . . . . . . . . . . . . . . . . . . . 149

© Copyright IBM Corp. 2000 vii

41. Content management using XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15142. Personalization in enterprise portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15343. Transcoding XML documents on-the-fly . . . . . . . . . . . . . . . . . . . . . . . . . 16144. Sample News DTD from ibm.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16345. Prototype architecture for ibm.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16446. IBM product suites in business-to-customer integration . . . . . . . . . . . . . 16647. IBM Enterprise Information Portal architecture . . . . . . . . . . . . . . . . . . . . 16748. Lotus Raven knowledge portal architecture. . . . . . . . . . . . . . . . . . . . . . . 16849. Integrating Lotus Raven and IBM Enterprise Information Portal . . . . . . . 16950. A sample screenshot of a Lotus Raven portal . . . . . . . . . . . . . . . . . . . . . 17051. WebSphere integrates users, data, applications; offers portal services . 17152. WebSphere transcoding customization . . . . . . . . . . . . . . . . . . . . . . . . . . 17353. TPAs within B2B XML frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18854. The TPA structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18955. The control point role of BPF in inter-enterprise business processes . . . 20556. General process flow for BPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20757. BPF functional layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20958. BPF set up environment and runtime operations. . . . . . . . . . . . . . . . . . . 21059. OBI Participants and flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21360. The OBI Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21561. TPA XML document building process within IBM Visual XML Builder. . . 21862. Creating a TPA XML model for the OBI TPA contract . . . . . . . . . . . . . . . 21963. Selecting the XML document root element . . . . . . . . . . . . . . . . . . . . . . . 22064. TPA document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22165. TPAInfo section of the TPA XML model for the two companies . . . . . . . 22466. Transport section of the TPA XML model for the two companies . . . . . . 22667. Document Exchange of TPA XML model for the two companies . . . . . . 22868. Service Interface section of TPA XML model for the two companies . . . 23069. Associating meta-data to a TPA field. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23270. Using the user-exit function in IBM XML Visual Builder environment . . . 23371. Group editing facility of the IBM XML Visual Builder environment. . . . . . 23472. Calendar editing facility of the IBM XML Visual Builder environment . . . 23573. TPA XML document source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23674. The eMarketPlace and the online intermediary business models . . . . . . 24475. The E-broker eMarketPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24876. Interactions between Traders and the E-broker Directory Service . . . . . 25077. TPA online building process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25178. The bulletin board auction information flow . . . . . . . . . . . . . . . . . . . . . . . 25379. The reverse auction information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25480. The regular auction information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25581. The multiple Request For Quotation aggregation service . . . . . . . . . . . . 25682. E-broker functional layers and main applications components . . . . . . . . 26283. Directory service: application topology . . . . . . . . . . . . . . . . . . . . . . . . . . 265

viii The XML Files: Using XML for B2B and B2C Applications

84. Auction service: application topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26685. Aggregation service: application topology . . . . . . . . . . . . . . . . . . . . . . . . 26786. Customer support service: application topology . . . . . . . . . . . . . . . . . . . 26887. The application topology of E-broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26988. Runtime topology of E-broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27089. Simple database model of a company. . . . . . . . . . . . . . . . . . . . . . . . . . . 277

ix

x The XML Files: Using XML for B2B and B2C Applications

Tables

1. Relationship between XML Features and e-business applications . . . . . . 332. Standard protocols and APIs: Network infrastructure . . . . . . . . . . . . . . . . 483. Standard protocols and APIs: Application server software . . . . . . . . . . . . 484. Standard protocols and APIs: Web application environment. . . . . . . . . . . 495. Standard protocols and APIs: System management . . . . . . . . . . . . . . . . . 496. Standard protocols and APIs: Development tools . . . . . . . . . . . . . . . . . . . 497. Standard protocols and APIs: e-business application services . . . . . . . . . 498. A pattern for each e-business solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . 539. Standard protocols and APIs: Network infrastructure . . . . . . . . . . . . . . . . 6110. Standard protocols and APIs: Application server software . . . . . . . . . . . . 6211. Standard protocols and APIs: Web application environment. . . . . . . . . . . 6212. Standard protocols and APIs: Development tools . . . . . . . . . . . . . . . . . . . 6213. Standard protocols and APIs: e-business application services . . . . . . . . . 6214. List of tools and utilities by category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6415. Product mappings for AIX and Windows NT . . . . . . . . . . . . . . . . . . . . . . 12816. IBM products and tools in building enterprise portals . . . . . . . . . . . . . . . 17417. XML B2B framework initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18218. The TPA Preamble section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19319. Product mappings for the E-broker runtime topology . . . . . . . . . . . . . . . 270

© Copyright IBM Corp. 2000 xi

xii The XML Files: Using XML for B2B and B2C Applications

Preface

When you get right down to it, e-business is a simple concept. An e-businessis an organization that connects critical business systems directly to keyactors such as customers, employees, suppliers, and distributors, by usingInternet technology. But this simple concept quickly becomes powerful. Ascustomers, employees, suppliers and distributors are all connected to thebusiness systems and information they need, e-business actually transformskey business processes. This book intends to present the emergence, andthe impacts of the Extensible Markup Language (XML) in e-business world.

By reading this book, customers, IBM sales people, IT architects, and ITspecialists will have the opportunity to understand how the “marriage”between XML technology and the IBM Application Framework for e-businesscan help to leverage e-business applications, particularly those based onbusiness-to-business (B2B), and business-to-consumer (B2C) models.

In writing this book, residents had many discussions with IBM people involvedin e-business, XML, and related technologies. They also “surfed the net” (IBMand non-IBM) to gather information about the e-business world in general, theIBM e-business vision and solution, and the XML technology applied to thee-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 somechallenges that arise through e-business applications such as dataexchange, portal services, and pervasive device support.

• How IBM cuts XML and related technologies down to size in its applicationFramework for e-business, including details of the IBM offering in terms ofarchitecture and tools to design, develop, deploy, and run complex B2Bmodels (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 thatdemonstrates the ability of XML technology combined with the IBMApplication Framework for e-business to implement both B2B and B2Cmodels.

© Copyright IBM Corp. 2000 xiii

The team that wrote this redbook

This redbook was produced by a team of specialists from around the worldworking at the International Technical Support Organization San Jose Center.

Luis Ennser is a consultant at the International Technical SupportOrganization, San Jose Center. He holds a Bachelor degree in MechanicalEngineering 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 ofXML, WebSphere, and Java. Before joining the ITSO, he worked as ane-business Solution Architect in Brazil.

Pietro Leo is an IBM IT specialist in the IBM SEMEA Sud - Java TechnologyCenter, Bari (Italy), organized under the IBM Global Services division. He haseight years of experience in Knowledge Management and ArtificialIntelligence. This includes five years of experience in IBM on Webapplications and object-oriented programming. He holds a degree inComputing Science from University of Bari (Italy), a Master of Science byResearch in Applied Artificial Intelligence from University of Aberdeen (UK,and a higher artistic degree in Music (a Diploma in OBOE) from the MusicConservatoir of Lecce (Italy). His expertise on customer projects includesareas of Knowledge Management, XML, Project Financing, KnowledgeBased Systems, Intelligent Agents, and Internet Personal Assistants.

Tamás Mészáros is a research associate at the Budapest University ofTechnology and Economics (BUTE) in Budapest, Hungary. He received hisM.Sc. degree in electrical engineering from BUTE. He has seven years ofexperience in networking technologies and artificial intelligence, and fouryears of experience in intelligent agents and Web application development.His areas of expertise include intelligent agents, Web application design anddevelopment, operating systems, and artificial intelligence. He has writtenextensively on intelligent agents, artificial intelligence methods, andintelligent product manuals.

Eric Valade is an IBM IT specialist in France. He has 10 years of experiencein EMEA technical pre-sale support for the application development area. Heholds a degree in Computer sciences from Pierre and Marie Curie Universityof Paris (France). His areas of expertise include software configurationmanagement, software development process, and programming. He haswritten extensively on IBM CMVC and IBM VisualAge TeamConnection.

xiv The XML Files: Using XML for B2B and B2C Applications

Thanks to the following people for their invaluable contributions to thisproject:

Joaquin PiconInternational Technical Support Organization, San Jose Center

Indran NaickInternational Technical Support Organization, Austin Center

Jonathan AdamsIBM UK

Joel FarrellIBM US

Martin SachsIBM US

Fernando LopezIBM US

Christina LauIBM Canada

John IbbotsonIBM UK

Comments welcome

Your comments are important to us!

We want our Redbooks to be as helpful as possible. Please send us yourcomments about this or other Redbooks in one of the following ways:

• Fax the evaluation form found in “IBM Redbooks review” on page 313 tothe fax number shown on the form.

• Use the online evaluation form found at ibm.com/redbooks

• Send your comments in an Internet note to [email protected]

xv


http://www.redbooks.ibm.com/contacts.html


xvi The XML Files: Using XML for B2B and B2C Applications

Part 1. Introduction to e-business and XML

This part of the book introduces the main issues concerning theemerging models of e-business applications on Internet and theimportance of XML in setting up these applications. It also shows whatproducts IBM offers to help customers in deploying e-businessapplications. We provide an overview of these areas for people whowould like to know more about these technologies from the customerand sales perspectives.

Chapter 1, “XML and e-business applications” on page 3) gives anoverview of e-business applications and XML. It includes a generalmodel of e-business applications, and identifies the main types(business-to-business, business-to-consumer, business-to-employeeand intra-company applications). It briefly introduces XML and relatedtechnologies, standards, organizations, and typical applications. Thelast part of this chapter summarizes how XML and related technologiescan be used in building e-business applications.

Chapter 2, “Introduction to IBM e-business solutions” on page 35introduces the IBM Application Framework for e-business. It describesthe architecture, programming model, design approach, ande-business cycle within the framework. It also shows how XMLtechnologies can fit into the e-business Application Framework on boththe client and server sides.

Chapter 3, “XML in the IBM Application Framework for e-business” onpage 59 presents the IBM XML initiatives and offerings related tobusiness applications, such as XML components; B2B frameworks,such as the announced WebSphere B2B Integrator; and extensions toother IBM products, such as the WebSphere family, DB2, VisualAge forJava, and MQ.

© Copyright IBM Corp. 2000 1

2 The XML Files: Using XML for B2B and B2C Applications

Chapter 1. XML and e-business applications

The purpose of this chapter is to provide you an overview of e-businessapplications and XML technology. First, we describe a general model ofe-business applications, and identify the main types: inter-businessapplications (business-to-business and business-to-consumer applications)and intra-business applications.

Next, we introduce the Extensible Markup Language (XML) and relatedtechnologies, standards and organizations, and we show some typicalapplications.

Finally, we summarize how XML and related technologies can be used inbuilding e-business applications.

1.1 About e-business

At the beginning of the Internet era, IBM invented the term e-business to givea proper name to a new class of powerful software applications and servicesthat, in its vision, should be developed in the following years. Theseapplications derive their power from combining the universal access andstandards of the Internet with the reliability, security, and availability ofexisting content, core business processes, and applications.

In very simplified terms, e-business refers to the use of Internet technologiesto improve and transform key enterprise processes. Most organizationsunderstand this, and have begun the transformation from traditionalapplications to their e-business counterparts. This transformation has begunto 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 includesintranet applications. e-business is the overall strategy, although e-commerceis an extremely important subset of e-business.

In what way is e-business different than the old order? Some characteristicsof the e-business model that set it apart from legacy business systems arethese:

• The e-business model facilitates transactions with a much wider group ofrespondents.


• 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 easilyfound 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, werecommend that you see the case studies discussed at the IBM Web sitehttp://www.ibm.com/e-business.

Following are some typical case studies:

• A commercial insurer developed an online billing inquiry system for agentsthat saves upwards of $5000 a month in call center expenses and acts asa platform for a wide range of agent communications needs.

• A retail bank offers Internet banking as a successor to direct-dial homebanking by supplying enhanced home banking features and servicesthrough the Internet. This application enables the retail bank to acquirenew accounts, transition existing customers to home banking, reduceoperating costs, and free up customer service personnel to providevalue-added services.

• A retailer implements an e-business supply chain solution to increasecollaboration with suppliers. In particular, the e-business solution providesthe retailer's suppliers with real-time sales and supply information alongthe entire supply chain. The solution has resulted in significantimprovements in shelf-availability of key products (from 87% to 98%) andtime required for product introductions and promotions.

• A government Motor Vehicles Registration Division improved service andreduced cost by creating a Web-based driver's license renewal processthat increases renewal alternatives, decreases transaction time, and cutsdirect transaction costs while helping the division maintain the same levelof operating budget.

These are only a few examples of the value that companies are creatingwhen they implement e-business. But, realizing this value is not simply amatter of establishing a Web site or a single, discrete, online application. Itarises from an e-business vision and an e-business roadmap that begins withan initial solution that is extendable into other high-value areas of thebusiness. e-business is not just about e-commerce transactions; it's aboutredefining old business models with the aid of technology.


In summary, an e-business is an organization that connects critical businesssystems directly to their customers, employees, partners, and suppliers, viaintranet, extranet, and over the Web. As customers, employees, suppliers,and distributors are all connected to the business systems and informationthey need, e-business actually transforms, innovates, and integrates keybusiness processes.

1.1.1 Business transformation and innovationThe convergence of Internet technologies, IT systems, and businessprocesses creates new business models: e-business models. Thus,e-business poses the most significant challenge to the traditional businessmodel. Computers have increased business speed by automating tasks, buthave not fundamentally altered the business foundation; e-business doesthis. If any entity in the value chain begins to do business electronically,similar companies must follow suit or risk being eliminated. Rethinking andredesigning the business model is not an option, but a necessary step tosurviving in the information era.

Companies have found that success in e-business is typically based onbuilding efficient value-added relationships with their customers. Thosecompanies exhibiting the highest degree of satisfaction and success withe-business consistently focus their strategy on improving their performancefor their customers. Whether simply making it efficient for a customer to placean order for a product or service, Web-linking and customizing access for asupplier network, or integrating a real-time collaborative productdesign/development process, the goal is to serve customers better.

Regardless of size or industry, companies follow a similar pattern ofe-business adoption. Figure 1 illustrates the typical e-business adoptionroadmap.

Chapter 1. XML and e-business applications 5

Figure 1. The e-business adoption process

The first two steps are typically a company’s introduction to using Webtechnologies — deploying intranet applications to communicate withemployees and establishing external Web presence with information aboutthe company and its offerings.

This experience has led companies to take the first steps toward reale-business — the establishment of pilots that give customers and suppliersaccess to the information contained in key business systems — for example,opening up the customer database that a service representative views andproviding 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 bankingoffered online banking.

The final two steps in the process offer the greatest opportunity for return, ascompanies transform their business processes by integrating multipleback-end systems to create a common user experience. As an example, anairline has integrated all travel systems and customer processes forbookings, upgrades, seat and meal selection, awards redemption, andfrequent flyer account management.

Awareness Presence Pilot AdoptionProcess

InvestmentCross-

ProcessIntegration

Use theInternet

internally

Establisha Web site

Allowaccessto key

systems(read only)

Allowtransactions

on keysystems

Improve keybusiness

process(es)

Redefinekey

process(es)


During these last two steps, not only can a customer buy or processtransactions online whenever they wish, but the company gains valuableinsight and knowledge about the specific needs and behaviors of itscustomers. They can also segment customers from a behavioral perspectiveas well as from a value perspective. However, without an initial effort to makethe data customer-ready, value for both the customer and the enterprise,though real, would be minimal. Many companies have begun offering onlinetransactions to reduce their costs without considering the value for theircustomers and, therefore, have not achieved sustained customercommitment to the system.

In the process investment phase, armed with this customer knowledge andwith the integration of business intelligence tools, analyses, and insights,companies can improve the customer relationship process by personalizingcustomer interactions online and integrating the customer view for their entireenterprise. Through these personalized interactions, customer retention andloyalty analysis can be applied to serving the customer more effectively at thepoint of need, rather than integrating this information after the fact.

Cross-process integration, the final phase in e-business evolution, focuses onintegrating across all the processes in an enterprise as well as acrosscustomer processes. For the enterprise, this means integrating all thecustomer touch points across all operational systems from supply to demandfulfillment, and through customer satisfaction. For the customer, it meanslinking the systems of all the suppliers involved in their process. Airlines, forexample, have integrated their booking systems with their frequent travelerservices internally and have linked into their travel partner systems to beginoffering passengers a single convenient point of fulfillment; retail banks areintegrating their services into a much broader single service access point fortheir online customers.

1.1.2 Which is the e-business value?There are several trends that are shaping the e-business necessity, and atthe same time, its value:

• Businesses of all sizes are impacted by globalization and deregulation,which lowers barriers to entry and dramatically reshapes the competitivelandscape.

• Customers now have a broader array of choices and, therefore, arebecoming more sophisticated and more demanding — both in what theywant from a supplier and how they choose to acquire goods and services.


• As a consequence of the fact that markets are becoming increasinglyfragmented (see the first two points above), mass marketing is fading inimportance as mass customization becomes the path to servingdiscriminating customers.

• Technology continues to evolve rapidly to support this environment. Theglobal reach of the World Wide Web enables companies to reachcustomers anywhere and to connect to employees, suppliers and tradingpartners wherever they are. This will create an expanding amount of data,which now can be mined for insight leading to better decisions — creatingways to know and serve your customers better and more profitably as wellas ways to gain a competitive advantage.

Thus, e-business can dramatically improve competitiveness and create newpaths to customer loyalty.

1.1.3 A simplified classification schema for e-business applicationsThere 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 playersat 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-businessapplications that have a company/organization internal scope. Theseapplications lie in the company/organization boundary and they areconnected to internal business activities. For example, this class includes therealization of an Intranet Information Web Site for company employees.

The second category, inter-business applications, includes all applicationsthat require some kind of interaction between the company/organization andsome other external entities, such as a customer, a company trading partner,or a financial institution. For example, as we will see better in the followingsections, an e-commerce application which models a buying/selling activitybetween a company and its customers over Internet is an inter-businessapplication as well as a Web-bank application, where, by using the Web, thebank customers can view their account balances, their recent transactions,and other financial data.


Classification of e-business activities, or business processes, is described inmore detail in the following sections. It is important to note that, although thefollowing sections make a distinction between intra-business applications andinter-business applications, from the infrastructure solution’s point of view,this distinction can disappear.

In fact, IBM has defined another convenient way to describe the architecturalnature of the e-business solutions that can be applied both to intra-enterpriseand inter-enterprise models. As the next chapter explains, recently IBM hasintroduced Patterns for e-business which will allow IT architects in 80% ofcases to quickly develop 80% of their required infrastructure by reuse ofproven architecture patterns, design patterns, and runtime patterns, as wellas offering design, development, and deployment guidelines and code.

Figure 2 illustrates the e-business application classification schema.

Figure 2. The e-business applications classification schema

One could argue that sometimes the boundary between an intra-businessapplication and an inter-enterprise application cannot easily defined.However, just for the purpose of this classification, we are referring tointra-business applications as all applications that are interfaced/useddirectly by company employees and/or other systems belonging to thecompany and are isolated from the external world. Complementary,inter-business applications are all those applications that can be interfacedby external end-users (for example, a customer) and/or externalapplications (trading partner applications).

Note

Company

Trading Partners

Customers

e-business applications

Redesignedapplications

Business ToEmployee

intra inter

Business ToBusiness

Business ToConsumer

Legacy


1.1.3.1 Intra-business applicationsMost intra-enterprise solutions are based on an intranet infrastructure wherethe purpose of an intranet is to share company information and computingresources among employees — usually, this class of applications are knownas business-to-employee (B2E). An intranet can also be used to facilitateworking 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 communicativeenvironment by making information accessible to ancompany/organization’s employees/members.

• Knowledge management: This is the identification and analysis ofavailable and required knowledge assets and knowledge asset relatedprocesses. Knowledge assets are the knowledge regarding markets,products, technologies, and organizations that a business owns or needsto own, and which enable its business processes to generate profits andprovide value.

Knowledge management means facilitating an environment whereknowledge, such as standards, common processes, and best practices,is shared and exploited by any group, department, or division in anorganization. This involves the process of capturing and leveraging acompany’s intellectual capital, which is a valuable commodity in manycompanies.

Knowledge management includes collaboration which exploits the Webtechnology to create team-oriented work environments that are moreproductive, higher quality, and enjoyable.

• Business intelligence: This means the development of applications ableto 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 andunderstanding needed to make informed decisions.


Using the latest e-business technologies, this intelligence can then bedistributed around your company or around the world helping to makecrucial and profitable decisions.

• Business process redesign: This means transforming inefficientpractices and processes inside the organization, from supply chainmanagement to internal procurement or expense reports.

1.1.3.2 Inter-business applicationsInter-business applications are all applications that require some kind ofinteraction between a company/organization and some other external entitiessuch as a customer, a company trading partner, a financial institution, orpublic administration departments. Inter-business applications can be dividedinto two main subclasses: business-to-consumer (B2C) andbusiness-to-business (B2B).

Inter-business application is the class of e-business application on which thisbook focuses and, as it will be better clarified in the following, it is also theclass 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 bythe consumer and, usually, are based around the Internet. The consumer isoutside of the organization using the service. This service could take the formof goods or information. It is also widely known as Enterprise Portals, to referto the set of Web-based applications that enable companies to connectcustomers to their information systems, and that provide a single gateway tothe personalized information needed to make business decisions.

Some of the services provided by a business-to-consumer solution may alsohold true for intra-company solutions. The following are some of the mostcommon 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 corporateinformation


• Customer self-service includes queries from customers (consumers orbusinesses), for example:

- Account inquiries- Customer service- Help desk

• Online ordering (Transaction/Dynamic) includes online order taking andbill presentation for any of the following:

- Electronic Catalogs- Web stores- Web selling- Web auctions

• Bill Payment (Transaction/Dynamic) includes online payment andtransaction handling.

Figure 3 shows how fast the business-to-consumer sector is growing.

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

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

SoftwareOtherGroceriesBooksComputers/CETravel

Billions

High Estimate

$300

$180

1998 1999 2000 2001 2002 2003


Business-to-business applications (B2B)These types of applications focus on using the Internet and/or extranet toimprove business-to-business partnerships and transforminter-organizational relationships. Companies can cut the cost of operationsand production, improve business processes, and deliver more value tomarket by leveraging e-business enhanced partnerships.

e-business feeds new kinds of relationships between organizations. Some ofthe newest types of relationships are:

• Automation, automating the exchange of information between businesses

• Collaboration, sharing information and knowledge between businesses formutual benefit

The most common process that is contained within this activity is supplychain integration. The supply chain integration refers to Web-enabling legacysystems to provide visibility to select partners, suppliers, and customers, andto integrate the supply chain into other corporate processes using customizedextranets. An organization may have already had some or all of its supplychain integrated using earlier technologies, such as Electronic DataInterchange (EDI).

The following are a few processes related to supply chain integration and howthey might be improved using the Internet:

• Supplier management

Reduce the number of suppliers, and get them to become partners inbusiness 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, andeliminating out-of-stock occurrences.

• Distribution management

Move documents related to shipping, such as bills of landing, purchaseorders, advanced ship notices, and manifest claims, into an electronicmode, thus, allowing improved resource planning.

• Channel management

Quickly disseminate information about changing operational conditions totrading partners. Technical, product, and pricing information can now beposted to electronic bulletin boards, allowing instant access.


• Payment management

Link the company, supplier, and distributors so that payments can be sentand received electronically, thus, eliminating thousands of labor hours perweek.

• Financial management

Enable global companies to manage their money in various foreignexchange accounts.

• Sales force productivity

Improve the communication and flow of information among sales,customer, and production functions, thus, creating greater access tomarket intelligence and competitor information.

Figure 4 shows how fast the business-to-business sector is growing.

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

1998 1999 2000 2001 2002 2003

OtherUtilitiesPetrochemicalsMotor VehiclesComputing/Electronics

Trillions

High Estimate

$3.2

$1.8

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


During recent months, the traditional B2B model, centered around thebuyer-seller transaction paradigm, is showing its limitations: it is definite inscale and displays only partial efficiency in terms of market economics. Toovercome these limitations, a new internet business model appeared whichsupports B2M2B and leverages existing B2B applications and technology.The M represents the eMarketPlace or online trading communities whichassist multiple buyers and suppliers in exchanging information andtransactions.

Trading communities are internet based hubs that focus on specific industryverticals (see, for example, the recent hub, Component Knowledge, launchedby IBM Global Services for the electronic components market) or specificindustry processes that use various market making mechanisms (auctions,exchanges, aggregation) to mediate any-to-any transactions amongbusinesses.

Through the trading communities (hubs), buyers and sellers can tradeelectronically with established partners and, at the same time, get access tonew markets and new parts of the supply chain. These eMarketPlaces can bepublic, where all members participate in an open, interactive buying andselling community; or private, which are invitation-only communities whosemembers participate in special pricing arrangements and/or product andservice offerings. Online trading communities have the potential to createexcellent and efficient markets.

A much more detailed description of the B2B online trading communities andtheir related issues is provided in Chapter 7, “B2B eMarketPlaces: a casestudy” 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 relatedstandards, the organizations behind this technology, and the current trends.This introduction does not cover the technical details of these standards. Fora 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 RedbookSG24-5479-00).


1.2.1 World Wide Web document standardsThe World Wide Web (WWW) became very popular and widespread in thepast 5 years. Trends in communication networks, personal computers, andoperating systems, as well as the underlying technology of the WWW, made iteasy to access and use. The Web relies on two main standards, theHyperText Markup Language (HTML) and the HyperText Transfer Protocol(HTTP). Implementations of these standards can be found on all majorplatforms of today’s computing systems, from personal computers tomainframes, regardless the operating system used on them.

Web browsers implement the HTTP protocol to receive content from the Weband display the received HTML documents to the user. They becameavailable on every platform and provide universal access and user interfaceto the http://www. On the other hand, Web servers were designed to deliverHTML files to browsers using the HTTP protocol. Due to the licensing policyof the first server and browser implementations (they were practically free touse, and the source code was also available), they soon became widespread.

HTML was designed to describe the presentational format of a document. It istext-based, therefore, a simple text editor is enough to create and edit HTMLdocuments. Internet Service Providers (ISPs) introduced Web services totheir customers to store and publish HTML files, and the WWW became a fastgrowing supply of information for the Internet community.

As more and more users published their Web documents on the Internet, andsoftware vendors introduced new features to their browsers, the HTMLstandard was extended by new, de facto components and features. However,it remained a limited standard in a way, because it concentrates on thepresentation, and not on the content.

The growing amount of data stored in HTML format, and increasing problemsof handling this data, led to a proposal of a new document standard for theWorld Wide Web, the Extensible Markup Language (XML).

1.2.2 A brief history of XMLIn 1969, an IBM team developed a document description language (theGeneralized Markup Language, GML) to solve the problem of differentdocument formats of various systems. GML formed the basis of many IBMdocumentation systems, including Script and Bookmaster. In the followingyears, the language evolved into the Standard Generalized MarkupLanguage, which became an international standard (ISO 8879) in 1986 forthe format of text and documents.


SGML is the document standard for big industries like airplane construction,automobile, and military. Its strengths are being an implementation-independent, generalized, structured, and extensible language. Thesefeatures made it popular for companies that create, handle, and distributelarge amounts of text data.

In 1989, researchers at the CERN European Nuclear Research Facilitydeveloped a hypertext version of the SGML standard, called HypertextMarkup Language (HTML) to solve information sharing tasks within theorganization. HTML inherited important features from SGML (such as beingstructured, implementation-independent, and descriptive), but it was alsolimited in many areas (it used a fixed set of element types, and itconcentrated on the presentation). These limitations were necessary to makethe language more simple for easy software implementation and editing.

However, the growing amount of data stored in Web systems put theselimitations into focus. The World Wide Web Consortium (W3C, theorganization behind the Web standards) introduced several extensions to theHTML standard to solve its interoperability and scalability problems, butfinally it decided to develop a new subset of the SGML standard, XML, forWeb use.

The Extensible Markup Language (XML) was developed to overcome thelimitations of the HTML standard. It retains most of the features of the SGMLstandard, but makes it easier to implement and use in the World Wide Webenvironment. It became W3C standard in 1998.

The initial draft of this new standard included ten key design goals, which areworth 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.


1.2.3 XML — a universal data formatXML is practically almost indistinguishable from SGML. It has almost all of thecapabilities of SGML that are widely supported by implementations, but it alsolacks some important capabilities of SGML that primarily affect documentcreation, not document delivery. That is because XML was not designed toreplace SGML in every respect, but only on the Web.

While HTML is a single markup language, designed for a particularapplication, XML is really a family of markup languages: in fact, you candefine any number of markup languages in XML. This means that almost anytype of data can be easily defined in XML. So, in addition to a universalcommunications medium (the Internet), a universal user interface (thebrowser), we now have a universal data format — XML.

XML is universal, not only by its range of applications, but also by its ease ofuse: its text-based nature makes it easy to create tools, and it is also anopen, license-free, cross-platform standard, which means anyone can create,develop, and use tools for XML. What also makes XML universal is its datadescription power. Data is transmitted and stored in computers in manydifferent ways: originally it was stored in flat-files, with fixed-length ordelimited formats, and then it moved into databases, and often into complexbinary formats. XML is a structured data format, which allows it to storecomplex data, whether it is originally textual, binary, or object-oriented. Tothis day, very few data-driven technologies have managed to address allthese different aspects in one package — except XML.

In markup languages, like XML, SGML, and HTML, the information pieces ina document are marked with beginning and ending tags. These markingsidentify the pieces according to the creator’s intentions (within the frame ofthe language). For example, in HTML, these tags instruct the browser as tohow it should present the data between the marks to the viewer. In SGML andXML, these tags can do more: they can describe the information content heldby the data between the marks. To define what is the meaning of the tagsused in a document, these languages use the document type definition (DTD)description. Document creators can select or create a DTD they want to useto specify the meaning of tags.

The DTD defines all elements used in a set of documents, and it alsospecifies the relation of these tags to each-other in a tree format. Eachelement has an element type name (tag name) and a set of attributes. Eachattribute consists of a name and a value. In XML 1.0, element type namesand attribute names are strings of (a restricted set of) characters, similar toidentifiers in programming languages.


1.2.4 A short comparison of XML and HTMLThe problem with data available in HTML format is that it is formatted forpeople to view, and not for computers to use. HTML consists of a pre-definedset of tags, primary for viewing purpose. This makes it a language that iseasy to learn and accessible, but since it only concentrates on thepresentation, it is hard to reuse the data in HTML format.

This is where XML enters the picture. As its name indicates, XML isextensible, which means that you can define your own set of tags and make itpossible for other parties (people or programs) to know and understand thesetags. This makes XML much more flexible than HTML. In fact, because XMLtags represent the logical structure of the data, they can be interpreted andused in various ways by different applications. See Figure 5.

Much of the value of the Web comes from re-using data. For example, one ofthe great success stories of the Web are the search engines. They work onthe basis of a universal communications method (HTTP), and a universalmarkup language (HTML), to catalog Web pages. However, search engineswork on very limited information, because only a tiny part of an HTMLdocument is designed to be used by a search engine (new XML basedinitiatives such as Resource Description Framework will make search enginesmore powerful; see 1.2.7, “Metadata (RDF and PICS)” on page 21). Imaginehow much more powerful search engines could be if the data that they searchwas stored in a simple, structured, re-usable format, that concentrates ondescribing the data, and not on the presentation.

A number of standards and specifications make XML more usable for theWorld Wide Web. The XML standard itself does not contain information aboutlinking documents together, referencing to each other, using stylesheets,defining document access interfaces, and so on. The W3C is working onrelated 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 representingstructured data, provides a solid basis for defining a wide variety ofapplication-specific languages and standards. A number of XML-basedspecifications are now under development at W3C and other industrialorganizations.


Figure 5. XML supports a number of other languages

In general, these specifications are work-in-progress. This means that mostof these specifications have not reached the standard level; they arecandidates for standards, working drafts, or proposals for newstandardization. For more information about their current status, visit theW3C 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 likestyling, enhanced type definitions, and accessing XML documents fromcomputer programs.

1.2.5 XML linking and addressingThere are specifications for linking and addressing XML documents. Linkingmeans establishing relationships between objects; addressing meansdescribing how to find linked objects.The XLink (XML Linking Language)specification describes constructs that may be inserted into XML resources todescribe links between objects. It can describe simple links like those inHTML, as well as more sophisticated multi-ended, typed links. The basic formof address is a Uniform Resource Identifier (URI, RFC 2396), which is a moregeneral form of resource location than the Web’s URL (Uniform ResourceLocator, RFC 1738).

XML

P3P

RDF

PICS . . .

SV

G

tpaML

SM

IL

XH

TM

L

. . .

resource description standards

domain specific standards


The XPath (XML Path Language) is a language for addressing parts of anXML document. It operates on the abstract, logical structure of an XMLdocument. The XPointer (XML Pointer Language) specification supportsaddressing into the internal structures of XML documents. It is an extensionXPath to address points, ranges, and nodes; to locate information by stringmatching; and to use addressing expressions in URI-references as fragmentidentifiers.

1.2.6 Advanced type definitionsThere have been several proposals to enhance the applicability of DocumentType Definitions. In a situation where different types of DTDs can exist withinthe same application (or document), a simple character string may not beenough to specify tags used in a document. The XML Namespacesrecommendation extends the data model to allow element type names andattribute names to be qualified with a URI.

Since the XML Document Type Definition is a restricted format (morerestricted than the SGML DTD), there are limitations when it comes todefining complex relationships between data elements and their usage,especially when XML documents also use namespaces which might defineelements conflicting with DTD declarations. To resolve these limitations, anew standard was proposed: XML Schema.

The purpose of a schema is to describe a set of document constructs toconstrain and document the meaning, usage, and relationships of theirconstituent parts: datatypes, elements with their content, and attributes withtheir values. Schemas specify richer models for data typing and inheritance.Schemas strengthen the document modelling and validating capability ofXML, and make it possible to express structural relationships betweendocument types.

1.2.7 Metadata (RDF and PICS)Metadata, or data about data, provides information about data objects. Thisinformation can be used to label and catalog data. Metadata helps inorganizing, locating, and understanding data. It provides a means to improvethe productivity of the data management process.

W3C's metadata activity is concerned with ways to model and encodemetadata — developing RDF and PICS, two metadata standards.


• Resource Description Framework (RDF, http://www.w3.org/RDF) integratesa variety of Web-based metadata activities, including site maps, contentratings, stream channel definitions, search engine data collection, digitallibrary collections, and distributed authoring. It is a declarative languageand provides a standard way for using XML to represent metadata in theform of statements about properties and relationships of Web resources.RDF also provides a framework in which independent communities candevelop vocabularies that suit their specific needs. The descriptions ofthese vocabulary sets are called RDF Schemas. A schema defines themeaning, characteristics, and relationships of a set of properties, and thismay include constraints on potential values and the inheritance ofproperties from other schemas. A well-known RDF Schema is the DublinCore, developed by the library community. RDF uses the idea of XMLNamespaces to allow RDF statements to refer to a particular RDFvocabulary.

• Platform for Internet Content Selection (PICS, http://www.w3.org/PICS)consists of a set of specifications which allows people to assign labels todigital information for describing metadata. Labels contain informationabout the content in simple, computer-readable form. This information canbe used according to user’s settings for filtering out undesirable materialor directing users to sites that may be of special interest to them. WhilePICS has general applicability to labelling pages for a variety of metadatapurposes, the PICS specification was originally designed to allow parentsand teachers to screen out materials unsuitable for children using theInternet.

1.2.8 Domain-specific document definitionsThere are specialized vocabularies (DTDs) for different application fields.These pre-defined DTDs define a common document structure for the givenapplication field to ensure that different application vendors use the sameelement definitions for same purposes.

There are DTD repositories where you can find definition files for yourapplication field. There are only a few standardized document definitions atthe time of writing this book, but it is expected that the number of thesestandardized DTDs will increase greatly as the industry leaders and standardbodies 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, dateand time, country codes, basic business forms, and descriptions ofbusinesses and individuals.


Vertical XML specifications describe a specific application area like electronicpayment, mathematics, or chemistry. For example, a specialized language fortrading is the Trading Partner Agreement markup language (tpaML) proposedby IBM, which will be described in detail in 6.2.1, “Trading PartnerAgreements” 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 basedon XML. This new document standard is called XHTML (Extensible HyperTextMarkup Language, http://www.w3.org/TR/xhtml1), that is now a W3CRecommendation. The XHTML 1.0 specification describes XHTML, areformulation of HTML 4.0 as an XML 1.0 application. This aims to moveHTML into the XML area while retaining its processing ability in standard Webapplications. XHTML is intended to be used as a language for content that isboth XML-conform and operates in HTML 4 conforming user agents.

1.2.9 XML in wireless applicationsWireless application environments are domains where XML has already beenplaying an important role. These applications have special requirements fordocument formats and rendering due to their limited bandwidth and displaycapabilities. There are several XML-related proposals to fit mobile devicesinto 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 dataformats to ensure that provide an effective way to access the Web frommobile devices. They are working on presentation languages as well as onresource description formats that can represent the capabilities of thesedevices.

The Composite Capability/Preference Profiles (CC/PP) specification iscurrently a W3C Note. It is a user side framework based on XML and RDFthat describes the capabilities, hardware, system software, applications, anduser preferences used by someone to access the Web. These informationmight include the preferred language, sound on/off, images on/off, class ofdevice (phone, PC, printer, or other), screen size, available bandwidth,version of HTML supported, and so on.


The Wireless Application Environment (WAE, http://www.wapforum.org)specification contains several documents that describe the applicationenvironment. It includes the WML, WBXML, WMLScript and its standardlibraries, and finally, the Wireless Telephony Application Specification and itsapplication interface specifications.

WML (Wireless Markup Language) is a markup language based on XML, andis intended for use in specifying content and user interface for narrowbanddevices, including cellular phones and pagers. WML includes four majorfunctional areas:

• It includes support for text and image, formatting and layout commands.

• Deck/card organizational metaphor structures information in a collection ofcards and decks.

• The inter-card navigation and linking supports the navigation betweencards 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 compactbinary representation of the Extensible Markup Language. It is designed toreduce the transmission size of XML documents without loosing functionalityor semantic information.

1.2.10 XML styling and transcodingThe Extensible Style Language (XSL) is a specification by the World WideWeb Consortium for applying formatting to XML documents in a standardway. XSL is based on the Document Style Semantics and SpecificationLanguage (DSSSL, ISO/IEC 10179), but it is simplified and designed for Webuse, and also has document manipulation capabilities beyond styling.Actually, the XSL specification is divided into two main documents. The XSLTransformations (XSLT) specification describes how to transform one XMLdocument into another, and an XML vocabulary specifies formattingsemantics. An XSL stylesheet specifies the presentation of a class of XMLdocuments by describing how an instance of the class is transformed into anXML document that uses the formatting vocabulary.

There are also ways of transcoding XML documents into another documentformats. Today’s typical application scenario for this type of documenttransformation is the server-based transcoding. For example, a Web servercan be extended to process XML files on the fly, and present HTML files for


its clients. This can also be tailored according to the client’s needs, forexample, a WAP client from a wireless phone would prefer different documentformats, than another from a home PC. The IBM WebSphere product familyoffers such document transformation using WebSphere Transcoding.

1.2.11 XML query languagesQuery languages and tools help accessing information in XML documents inan efficient way. While XSL allows information access by filtering the requiredelements, it is very limited tool for this purpose. There are several proposalson extending the XSL standard with more powerful query and searchcapabilities.

At the time writing this book there was no standard technology for buildingand processing XML queries. The W3C created a draft recommendation onXML Query Requirements (W3C Working Draft, 31 January 2000, available athttp://www.w3.org/TR/xmlquery-req), and there are several initiatives toformulate a standardized language.

The XML Query Requirements document identifies what properties an XMLQuery Language must, should and may have. It includes generalrequirements, like language syntax, declarability, protocol independence, anderror conditions. The document also describes requirements for the XMLQuery Data Model, that relies on the XML Information Set. Finally, itdiscusses 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-QLproposal draws from database technology traditions. It is more concernedwith large repositories, integration, creation of new views of existing data, andtransforming data into common data-exchange formats. The XQL standard(from the document community) is more concerned with integrating full-textand structured queries, describing the structured search, and creatingmultiple presentations from a single document.

1.2.12 Processing XML documentsAt the heart of every XML application is an XML parser that processes anXML document, so that the document elements can be retrieved andtransformed into data that can be understood by the application and task inhand. The other responsibility of the parser is to check the syntax andstructure (validity and well-formedness) of the document.


Anyone has the freedom to implement a parser that can read and print anXML document. The XML 1.0 Recommendation defines how an XMLprocessor should behave when reading and printing a document. There areseveral 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 datafrom or put its own data into XML format. To provide this functionality parsersspecify an application programming interface (API). The XMLRecommendation does not specify this API, therefore it is up to the parser’sdesigner 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 numberof people on the xml-dev mailing list on the Web, because a need wasrecognized 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 forinterfacing with an XML parser, with many commonly available Java parserssupporting it.

SAX is an event-driven lightweight API for accessing XML documents andextracting information from them. It cannot be used to manipulate the internalstructures of XML documents. As the document is parsed, the applicationusing SAX receives information about the various parsing events. The logicalstructure of an application using SAX API with the parser is shown inFigure 6.


Figure 6. SAX application components

The SAX driver can be implemented by the XML parser vendor, or as anadd-on to the parser. That makes the application using the parser via SAXindependent of the parser.

The Document Object Model (DOM) API is a set of interfaces that must beimplemented by a DOM implementation such as IBM’s 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 methodsto navigate and manipulate the tree-structure of XML documents. Themethods include getting, deleting, and modifying the children of a node, aswell as inserting new children to it. Document represents the wholedocuments, and the interface define methods for creating elements,attributes, comments, and so on. Attributes of a Node are manipulated usingthe methods of the Element interface. DocumentFragment allows extractingparts of a document. It should be noticed that while a DOM application readsan XML document and an object representation if formed, that representationremains only in memory. Changing a DOM object in memory does notautomatically modify the original file. That is something an applicationprogram has to do for itself.

X M L A P P L IC A T IO N

S A X A P I

X M L P A R S E R

X M L D O C U M E N T


Figure 7. DOM interface hierarchy

Some important facilities that are missing from the DOM Level1Recommendation are being defined in DOM Level 2, which is currently aW3C Candidate Recommendation (10 December, 1999). The addedfunctionality in Level 2 contains interfaces for creating a document, importinga node from one document to another, supporting XML Namespaces,associating stylesheets with a document, the Cascading Style Sheets objectmodel, the Range object model, filters and iterators, and the Events objectmodel.

There are certainly applications that could use either SAX or DOM to get thenecessary functionality needed when processing XML documents. However,these two approaches to XML processing each have their strengths andweaknesses.

SAX provides a standardized and commonly used interface to XML parsers. Itis ideal for processing large documents whose content and structure does notneed to be changed. Because the parser only tells about the events that theapplication is interested in, the application is typically small, and has a smallmemory footprint. This also means that SAX is fast and efficient, and a goodchoice for application areas such as filtering and searching, where onlycertain elements are extracted from a possibly very large document.

N ode

N odeL ist

N am edN odeM ap

D O M Im plem e nta tion

A ttr

C haracterD ata

Docu m entTyp e

D ocum entF ragm ent

Docu m ent

E lem ent

E ntity

E ntityReferen ce

Nota tion

P roces sing Instruction

Com m ent

Text CD A TA Sec tion

D O M E xc eption(c lass)


Because the events must be handled as they occur, it is impossible for a SAXapplication, for example, to traverse backwards in the document that is underprocessing. It is also beyond SAX’s capabilities to create or modify thecontents and internal structure of an XML document.

Because every element of an XML document is represented as a DOM objectto the application using the DOM API, it is possible to make modifications tothe original XML document. Deleting a DOM node means deleting thecorresponding XML element and so on. This makes DOM a good choice forXML applications that want to manipulate XML documents, or to create newones.

DOM is not originally an event driven API like SAX, even though the DOMLevel 2 draft specifies events. To extract even a small piece of data from anXML document, the whole DOM tree has to be created. There is no way ofcreating lightweight applications using DOM. If the original XML document islarge, the DOM application that manipulates the document requires a lot ofmemory. In practice, DOM is mostly used only when creating or manipulatingXML documents is a requirement.

There are other initiatives to specify application interfaces to XML documentsin various environments. There are native APIs for different programmingplatforms, like Pyxie for Python (http://www.pyxie.org), or the Java API forXML Parsing (JAXP, java.sun.com/xml), and XML components for variousapplications 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 amore detailed description about DOM and SAX, and application examples,read “The XML Files: Using XML and XSL with WebSphere 3.0” by LuisEnnser, Christophe Chuvan, Paul Fremantle, Ramani Routray and JoukoRuuskanen (IBM Redbook SG24-5479-00).

1.2.13 Organizations concerned with XMLThere are standard bodies, civil organizations, and industrial groups andcompanies behind the specification of XML and related standards.

The ISO (International Standards Organization) handles several relatedstandards, 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


they call their standards) on XML, XSL, XPath, Namespaces, MathML, andother related technologies. It also issues Proposed Recommendations(Recommendations before the W3C Advisory Committee reviews them),Candidate Recommendations (published for external review), and WorkingDrafts (submitted for review by W3C members).

The largest industrial consortium to promote the structured documentmanagement technology (SGML and XML) is the Organization for theAdvancement of Structured Information Standards (OASIS,http://www.oasis-open.org). It is a non-profit, international consortium of usersand suppliers (including IBM) whose products and services support SGMLand XML. OASIS operates XML.ORG, the a global XML industry Web sitefeaturing an XML registry and repository that offers automated public accessto XML schemas for electronic commerce, business-to-business transactions,and tools and application interoperability. The annual SGML/XML 'XXConference and the corresponding SGML/XML Europe Conference areco-sponsored by OASIS (together with the Graphic CommunicationsAssociation), as are other major SGML/XML events.

CommerceNet (http://www.commercenet.com) is a non-profit globalmembership organization whose mission is to “promote and advanceinteroperable electronic commerce to support emerging communities ofcommerce”. It runs several research projects about XML topics.

BizTalk (http://www.biztalk.org) is a Microsoft initiative whose goal is “drivingthe rapid, consistent adoption of XML to enable electronic commerce andapplication integration”. It defines the BizTalk Framework™, a set ofguidelines for how to publish schemas in XML and how to use XML messagesto easily integrate software programs. It runs independently from otherindustrial organizations like OASIS and CommerceNet.

1.2.14 Typical applicationsIn this section we present three examples of how XML is being used inreal-life to bring benefits to people, businesses, and organizations. For moreexamples, see the XML section in the IBM developerWorks site at:http://www.ibm.com/developer/xml

XMLSolutions extends EDI applications to non-EDI partnersXMLSolutions XEDI Translator integrates existing electronic data interchange(EDI) systems to XML-based system, providing both X12 and EDIFACTtranslations to XML. This technology can dramatically reduce the overall costof electronic commerce systems. This technology enables non-EDI tradingpartners to participate in EDI transactions, thus reducing trading costs. A


majority of the Global 2000 companies have between 10,000 and 40,000trading suppliers, 80% of those have not implemented EDI trading. By usingXMLSolutions XEDI Translator this majority of the trading partners can alsoparticipate in electronic transactions. IBM WebSphere, WebSphere Studio,and VisualAge for Java are used to implement XMLSolutions products.

Navant Corporation develops Web of Knowledge using XMLThe Web of Knowledge e-business platform has built-in capabilities forbuilding enterprise portals, online communities, performing online education,and webcasting. It addresses several business challenges including businessintegration, employee education and collaboration, Intranet management,online commerce, and online Internet content. Web of Knowledge uses XMLfor its business object persistence, site content markup, message exchange,template-driven customizable interfaces, client-side data islands, andconfiguration. It uses XSL for server-side data transformation and filtering,and for client-side filtering. Using the XML standard guarantees that the datawill be interoperable between business applications. Web of Knowledge isbased on IBM’s WebSphere solution and DB2 database system as thepreferred infrastructure to be used in support of the product.

SABRE and Wireless Markup LanguageThe SABRE Group is one of the major distributors of international travelservices, offering electronic travel bookings through travel agents and on theWeb worldwide. They are transforming their travel information into XML usinga Java application, and then allowing mobile phone users worldwide to lookup, reserve, and purchase travel from a mobile phone. The XML isautomatically translated from XML into Wireless Markup Language, which isa standard for building applications on mobile phones. The benefits of XML tothis application are its extensibility, the speed of development, and the abilityto build a standard repository in XML, and translate as needed into aparticular 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 yourcritical business systems.

From the development team’s point of view, this means they no longer haveto use proprietary mechanisms for formatting data passed betweenapplications or stored in files or databases. From the vendors’ and businesspartners’ points of view, this means they can easily exchange information.


Finally, for the e-business, XML provides an open, cross-platform way totransact, manage, and share information.

Businesses can leverage data currently residing in hard-to-reach ornon-integrated legacy systems and share information across theheterogeneous environment of the Web. XML helps improvebusiness-to-business transactions by combining the power of electronic datainterchange (EDI) with the simplicity of the Web. This combination oftechnologies fuses Web data interchange — based on XML— with existingEDI business methods and structures.

For example, using an XML-based solution, the health care industry cancreate vocabularies for medical patient information that can be easily sharedamong doctors, insurance companies and patients. This capability enablesmedical professionals to access common information — without worryingabout the hardware and software that they use to run their respectivebusinesses. In this way, patients will benefit of a more efficient processing ofmedical claims between doctors and insurance companies, tighter integrationof 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 easilyunderstand.

• Extensible

Diverse data with specific meaning for a given community can be freelyexchanged. You can invent custom tags and vocabularies for any purposeand share them across interest groups.

• Interoperable

Data sharing does not depend on any particular software or hardwareplatform.

• Mature

Although the specification was announced in February 1998, it is asimplification of the proven SGML technology that originated from IBMresearch in the 1960s.

• International

Built-in support for Unicode, an international language encoding standardthat supports any script in the world today. This makes transnational dataaccessible to the programmer.


Table 1 summarizes the relationship between main XML feature ande-business applications.

Table 1. Relationship between XML Features and e-business applications

XML has the potential to be the standard language of inter-enterprisebusiness integration: if company information systems, applications, and so onare XML-compliant, then data can be easily exchanged between them.However, XML alone cannot be the solution to the business integrationproblem. XML itself is not a business data description language; rather, it is aspecification language that can be used to build the former. As we will see inthe second part of this book, companies, industrial consortiums andorganizations are still working to formulate XML schemas to be used in doingB2B transactions.

XML Feature Relationship in the inter-businessapplications

Sharing data across platforms andapplications

Data tagged with XML in one applicationcan be understood in another. The XMLtags permit content sharing across thecompany/organization Intranet as well asExtranet.

Reusing information efficiently Company information created in XML andstored in a document managementsystem has a longer life span — helping toensure future readability as well as reusetoday and tomorrow.

Improving customer satisfaction The XML metadata capabilities helpsoftware to personalize end-userexperiences without complexprogramming. You can modify datapresentation for different client devices.

Using XML in an open, standardenvironment

XML is a critical component to completingthe technology foundation necessary fore-business, removing directdependencies between data and thesoftware that uses it.


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 technologyto improve business processes. We categorized e-business applications asbeing intra-business or inter-business systems, and we gave detaileddescriptions of these categories. As a key example in intra-businessapplications, business-to-employee (B2B) systems, which facilitateinformation sharing within the company, were briefly introduced. The twomain areas of inter-business cooperation are business-to-business (B2B) andbusiness-to-consumer (B2C).

B2B applications help companies in establishing electronic transactions andpartnership over the Internet. They enhance business process automation,collaboration with other companies, and establish virtual markets andcommunities. B2C applications help companies to automate and enhancetheir customer relations. Using B2C solutions, companies can create andmaintain information sites, automated customer service, help desks,electronic catalogs, and Web stores. These solutions help in marketing, salesand support.

The Extensible Markup Language is a key technology to build e-businessapplications, since it is a platform and vendor independent documentstandard for describing structured data. As a universal data format, it enablesthe seamless connection to business partner systems. It is based on an ISOindustry standard (SGML), and it is created for Web use. In the secondsection of this chapter we introduced this technology, showing its key featuresand areas. We have also shown application examples, where XML was usedto enhance business applications.

Finally, in the last part of the chapter, we summarized the impact of XML one-business. We gave a list of advantages that XML provides in e-business,and we analyzed the relationships between the main XML features and thee-business applications.


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. TheInternet is not only providing a communication medium for the masses — it isalso enabling business-to-business relationships to soar to new heights. Theunderlying technologies enabling this fundamental revolution have openedthe door for the development of the next generation of business applications.

If you are involved in that revolution, you have certainly heard about the IBMe-business cycle and the IBM Application Framework for e-business. If youalready 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 transformbusinesses into e-business, the application architecture, the programmingmodel, then this chapter aims to give you some basics.

2.1 IBM e-business cycle

Most companies have begun the transition from traditional business toe-business. They have established Web sites and have started toWeb-enable such core processes as self-service applications to strengthencustomer service operations, to better connect with their supply chains andreach new and existing customers. However, the next step is integratingbusiness processes. IBM finds that it’s not just Web-enabling that counts, butlinking 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 equallyclear picture of how to make that vision a reality. The e-business cycle shownin Figure 8 is the IBM model for how customers can transform and innovatetheir businesses into e-businesses.


Figure 8. IBM e-business cycle

Transforming core business processes

Transforming core business processes is about doing business in newways by applying Internet technologies to create maximum value for yourbusiness. It's about how e-business (and not just technology) changes therules for Customer Relationship Management, Supply ChainManagement, and Electronic Commerce. IBM’s key differentiator in thenetworked world is business value. IBM can help you create the vision,and supply the solutions and services that will help you achieve maximumvalue as you make the transition from traditional business to e-business.

Building new and innovative applications

Transforming core business processes requires a new generation ofapplications. They run on servers, leverage existing applications and data,and scale to meet user demands. IBM can design, develop, and integratethese applications or makes it easy for you to develop them yourself. TheIBM Application Framework for e-business is designed to help you buildand deploy a new generation of applications that are open, flexible andeasy to change. Thus, e-business continues to be about starting simpleand growing fast.

Runnings a scalable, available, safe environment

The infrastructure squeeze play is real. Businesses are looking for a betterreturn on investment. Users want systems that are easy to use, yet always

Leverage Transform

BuildRun

knowledge andinformation

core businessprocess

a scalable,available, safe

environment

newapplications


responsive. IBM’s solution is to provide an environment with scalableservers, flexible clients, and advanced storage devices — all handled in asecure, manageable way. IBM strategic advantage is in helping you Buildon what you have — offering cross platform integration and a completerange of services from in-house management to Web hosting to fullstrategic outsourcing services.

Leveraging knowledge and information

This is about creating a responsive organization that makes intelligent useof all types of data and organizational knowledge. By enabling profilingand personalization, e-business allows you to use data as a weapon. IBMhas Business Intelligence and Learning services that can help you createfaster, smarter organizations. IBM Business Intelligence solutionsleverage the data within your company. IBM Knowledge Managementsolutions help you capitalize on human experience to create a moreresponsive culture.

2.2 IBM Application Framework for e-business

Application Framework for e-business is an IBM-defined model that improvesthe customer’s chance of success. Research was conducted to betterunderstand the issues that application developers deal with as they buildInternet-based applications. Included in the research was participation fromcorporate and commercial application developers, as well as both IBM andnon-IBM customers.

The customers involved in the research were developing sophisticatedInternet, intranet, and extranet applications in multi-platform environments.They indicated that there was no road map for developing applications thatspan multiple platforms — and told IBM they would welcome a provenapproach that combined products as well methodology. IBM was viewed asone of the few vendors who could provide such a road map due to ourcommitment to standards and knowledge of multiple platforms. In response,IBM has delivered a model to design, develop and deploy this new class ofe-business applications.

The IBM Application Framework for e-business is a combination of:

• A set of industry standards and technologies

• Proven methodology

• Leadership products

Chapter 2. Introduction to IBM e-business solutions 37

The Framework is based on what has been proven successfully over the lastthree years as IBM has worked closely with customers to help them developand deploy the e-business applications that are transforming theirbusinesses. In this section, we will not be covering the IBM ApplicationFramework for e-business in detail. Rather, we will introduce the generalconcepts and objectives of the Framework.

2.2.1 Using an asset-based approachToday’s approaches to solution development are still primarily based onhandcrafting and bear little relationship to the asset-based engineeringmethods so successfully used in other disciplines. Handcrafting approachesare obsolete, and a more disciplined and constrained method is needed forsolution development.

2.2.1.1 Traditional problemsToday, the most common model for solution development is based on anapproach that could be called heroic. A highly-skilled energetic team studiesand refines the stated requirements, defines the architecture for a solution tomeet those requirements, carries out a detailed design, and builds thesystem. The primary assets brought to the table are the skills and experienceof 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 clearthat it is no longer adequate for today’s enterprise-scale systems.

In 1996, surveys of twenty major enterprise solution development projects inNorth America and Europe showed that solution development project riskincreased rapidly with project size. For projects requiring more than onehundred person-years, the risk of project delay or failure was very high.Moreover, for various reasons, the amount of project resources needed toreplace existing business systems is rising rapidly.

In the 1960s, utility billing systems could be developed in fifty person-yearsusing 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 the1980s, the figure was up to one hundred fifty person-years with moresophisticated personal computer (PC)-based interfaces.

However, by the mid-1990s, with the advent of object-oriented front ends anddistributed logic, client/server, and other technologies, several projects wereup to five hundred person-years with an elapsed time of four to five years. Aconsiderable part of this effort, perhaps one-third, was spent on integratingnew functions with existing (legacy) IT systems and handling data migration


to new database designs. These figures are not unique to the utilitiesindustry. The same trends are apparent in the insurance industry. Specifically,the replacement of existing contract management systems in a largeinsurance company in France was recently reported to have consumed fivehundred person-years over an elapsed time of six years or more.

It goes without saying that any project of five hundred person years isexposed to considerable risk — not only the risk of technical failure, but alsothe risk that, upon final delivery, the business requirements will have changedbeyond recognition, and the delivered solution may no longer meet businessneeds. These are known as instant legacy solutions.

Older or legacy systems frequently seem, to the end user, to bedisconnected, with independently-operating silos. For example, in aninsurance company, one IT system may deal with life insurance business andanother with general business, such as car insurance. More likely, the lifeinsurance 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 anenterprise to communicate with its customers separately from each system.To put it in a more positive way, a more coherent view of a customer thatconsiders all products held by that customer provides excellent marketingopportunities and improved customer retention; so, the existence of silos,typically manifested both through incompatible hardware and incompatible orsegregated software, is a serious issue.

Many development efforts start from scratch, and architectural componentsare integrated to create a custom architecture without the use of a templateor blueprint. Frequently, the project creates extensive custom middle ware,which might not have been needed if a blueprint-driven approach had beentaken. The selection of products from vendors is left to the skill of one or afew key architects. As a consequence, the solution takes longer to developand deliver, and the costs and risks are higher. Along the way, opportunitiesto leverage existing products, services, the prior integration of components,and the opportunity to acquire knowledge for subsequent reuse have beenlost.

When combining this risk with the likely development costs of fifty milliondollars or more, it is apparent that our industry is facing a crisis. In thesecircumstances, it is not surprising that enterprises are seeking to mitigate riskby taking an asset-based approach.


2.2.1.2 Using a sound architectureA sound architecture is an essential prerequisite for the successfuldevelopment of an enterprise-scale IT solution:

• It aids communication among stakeholders. The architecture is a basis forensuring mutual understanding.

• It represents the earliest design decisions about a system — decisionsabsolutely critical in terms of development, deployment, and futuremaintenance costs. For example, in development, they play a crucial rolein team organization, and this is later reflected in the organization of thecompany for which the solution is being developed. In maintenance, theflexible qualities built into the architecture will be key to the ability of thesolution 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 architectureteam 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 ofarchitectural styles, or it can reuse and build upon an existing Framework.

A Framework is a reusable design expressed as a set of abstract patternsand the way their interfaces collaborate. It is a reusable design for all or partof a software system; a User Interface Framework only provides a design forthe user interface of a system, while an Application Framework provides adesign for the entire application. Early Frameworks revolved aroundprogramming languages, such as an object-oriented design. ApplicationFrameworks do not have to be implemented in an object-oriented (OO)language, but they do have characteristics similar to OO design, in thateverything 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, andservices necessary to create, deploy, and manage complex e-businessapplications. The programming model, the architecture of technologies(and tools), and e-business disciplines, such as customer relationshipmanagement (CRM) and supply chain management (SCM) — all overlay theApplication Framework.

2.2.1.3 Advantages of IBM Application Framework for e-businessThe IBM Application Framework for e-business:

• Provides you a programming model that puts you on the fast track.


• Helps you work with multi-platform standards like Java and technologieslike CORBA and XML.

• Explains the characteristics of application servers and how to connect withclients of all types.

• Guides you to more information on network, data, and infrastructurestandards.

IBM Application Framework helps you build and deploy, so you can write anapplication on one platform and run it somewhere else without completelyrewriting the code. The Framework offers the fastest way to develope-business applications and integrated software, server, and services, whenyou are faced with the unique development and deployment challengesinvolved in building e-business applications that are scalable, work acrossmultiple platforms, and integrate with existing applications.

The benefits of developing applications using the IBM Application Frameworkare illustrated by the key principles that have guided its development:

• Maximize ease and speed of development and deployment. By adopting aserver-centric, Java based component model and toolset, your e-businessapplications can be developed and deployed quickly with skills rangingfrom non-technical graphic designers to programmers.

• Accommodate any client device. Support of Internet standards and aserver centric model expands access to your e-business applications to abroad range of client devices.

• Ensure portability across a diverse server environment. Support of theopen, unifying Java platform makes it easy to deploy your e-businessapplications on the systems that best meet your scalability and quality ofservice requirements.

• Leverage and extend existing assets. To improve time to market andreduce cost of development, e-business applications must leverage andextend the reach of secure, reliable, and scalable applications that are thecore of many business processes.

• Flexible and extendable. Able to accommodate future technology, such aspervasive computing, Internet2.

The IBM Application Framework for e-business programming model is usedas a basis for the design of e-business applications. This model has evolvedfrom the traditional client/server computing model. The key properties ofapplications based on this model are as follows:


• Universal connectivity based on HTML/Java-enabled thin clients, that is,manageable clients that can be configured so they do not require localsoftware installation and data backup, such as the IBM WorkSpaceOn-Demand Client solution.

• Rapid development of write-once-run-anywhere applications withjust-in-time deployment.

• Software reuse to minimize new code, promote quality, and maximizeproductivity.

• Universal access to data

• Workload optimization across servers

• Application deployment is independent of client and server operatingsoftware and hardware.

• Connections to external services where existing business applications anddata reside leveraging their value for customers, business partners, andemployees.

Moving applications to the e-business model also brings design problems thatmany developers may never have faced before. Among the new factorsdevelopers must now consider are the following:

• Web Browser clients and other new technologies and paradigms such aspervasive 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 nextsection depicts the foundation of the IBM Application Framework fore-business.

2.2.2 Overview of the IBM Application FrameworkTo transform traditional business processes in order to become ane-business, you will need a foundation for developing new businessapplications. IBM's answer is the Application Framework for e-business, acomprehensive, scalable platform that supports all the services needed todevelop and deploy e-business solutions.

The IBM Application Framework for e-business provides a model for designinge-business solutions. The Framework is based on an n-tier distributedenvironment where any number of tiers of application logic and businessservices are separated into components that communicate with each other


across a network. In its most basic form, as shown in Figure 9, the Frameworkcan be depicted as a “logical” three-tier computing model, meaning that there is alogical, but not necessarily physical, separation of processes. This model isdesigned to support clients with high-function Web application and enterpriseservers.

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 througha browser, Java applet, or pervasive computing devices.

• Web application servers containing the business logic and processes thatcontrol the reading and writing of data.

• Servers that provide the data storage and transactional applications usedby the Web application server processes.

The application elements residing in these three logical tiers are connectedthrough a set of industry-standard protocols, services, and softwareconnectors.

Content EnterpriseJavaBeans

Thin client

WebApplicationServers

Connectors

Network infrastructure that usesindustry standard APIs andprotocols

E xternalS ervices


2.2.2.1 Application Framework ArchitectureThe IBM Application Framework for e-business architecture provides a fullrange of services for developing and deploying e-business applications.Because it is based on industry standards, the Framework has the ability toplug-and-play components provided by almost any vendor.

The model identifies key elements for developing and deploying e-businessapplications as shown in Figure 10. Each element is based on open,vendor-neutral standards, allowing you to substitute components from anyvendor that supports those standards.

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 thatenables universal access to Framework applications, and on-demanddelivery of application components.

• A network infrastructure that provides services such as TCP/IP, directory,and security whose capabilities can be accessed via open, standardinterfaces and protocols.

C o n te n t E n te r p r is eJ a v a B e a n s

c l ie n ts

W e bA p p l i c a t io n

S e r v e r s

E x te r n a lS e r v ic e s

e - b u s in e s s A p p l ic a t io nS e r v ic e s

W e b A p p l ic a t io n P r o g r a m m in gE n v i r o n m e n t

A p p l ic a t io nS e r v e r

S o f tw a r e

A p p l ic a t io nIn te g r a t io n

N e tw o r k In f r a s t r u c tu r e

S y s te m M a n a g e m e n t

To o ls

J a v a


• Application server software that provides a platform for e-businessapplications and includes an HTTP server, database and transactionservices, mail and groupware services, and messaging services.

• Application integration that provides access to existing data andapplications.

• A Web application programming environment that provides the server-sideservlet and Enterprise Java programming environment for creatingdynamic and robust e-business applications.

• e-business application services that provide higher level applicationspecific functionality to facilitate the creation of e-business solutions.

• Systems management functions that accommodate the uniquemanagement requirements of network computing across all elements ofthe system, including users, applications, services, infrastructure, andhardware.

• Development tools to create, assemble, deploy, and manage applications.

ClientsClients supported by the Framework are “thin clients”, meaning that little orno application logic is executed on the client and therefore relatively littlesoftware is required to be installed on the client. In this model, applicationsare managed on the server and dynamically downloaded “on-demand” torequesting clients. As such, the client portions of new applications should beimplemented in HTML, Dynamic HTML, XML, and Java applets. TheFramework supports a broad range of fixed, mobile, and “Tier 0" clients suchas personal digital assistants (PDAs), smart cards, and digital cell phones,from IBM and other industry leaders, based on industry initiatives such as theNetwork Computer Profile, and the Mobile Network Computer ReferenceSpecification.

Network infrastructureThe network infrastructure provides a platform for the entire architecture. Itincludes the following services, all based on open standards:

• TCP/IP and network services like DHCP that dynamically assigns IPaddresses as devices enter and leave the network.

• Security services based on public key technology that support useridentification and authentication, access control, confidentiality, dataintegrity, and non-repudiation of transactions.

• Directory services that locate users, services, and resources in thenetwork.


• Mobile services that provide access to valuable corporate data to thenomadic computing user.

• Client management services that support the setup, customization, andmanagement of network computers, managed PCs, and in the future Tier0 devices such as smart cards, digital cell phones.

• File and print services that are accessed and managed via a standardWeb browser interface.

Application server softwareThe application server software layer provides the core functionality requiredto develop and support the business logic of e-business applications runningon the Web application server. It includes the following services:

• An HTTP server that coordinates, collects, and assembles Web pagescomposed from static and dynamic content and delivers them toFramework clients.

• Mail and community services that provide e-mail messaging, calendaringand group scheduling, chat, and news group discussions.

• Groupware services that provide a rich shared virtual work space andsupport the coordination of business workflow processes.

• Database services that integrate the features and functions of anobject-relational database with those of the Web application server.

• Transaction services that extend the Web application server by providing ahighly available, robust, expandable and secure transactional applicationexecution environment.

• Messaging services that provide robust, asynchronous communicationand message brokering facilities that support a publish/subscribe model ofcommunication and message transformations.

Application integrationThe application integration component of the Framework allows disparateapplications, potentially written in different programming languages and builton different architectures, to communicate with each other. The bulk oftoday's critical data and application (especially transactional) programsreside on and use existing enterprise systems. Application integration allowsWeb clients and servers to work together with this data and these applicationprograms, seamlessly linking the strength of the Internet with the strength ofthe enterprise. Three methods of integration are supported:

• Connectors are gateway software that provide linkage between the Webserver and services that are reached through the use of applicationspecific protocols.


• Messaging services provide asynchronous communication and messagebrokering facilities, including message transformations.

• Managed object services enable object wrappering of existing applicationlogic written in any language. As a result, existing application logic isextended to object-oriented environments.

Web application programming environmentThe Web application programming environment, based on Java servlets,Enterprise Java services and Enterprise JavaBean components, provides anenvironment for writing dynamic, transactional, secure business applicationson Web application servers. Services are provided that promote separation ofbusiness and presentation logic enabling applications to dynamically adaptand tailor content based on user interests and client device.

e-business application servicesThe e-business application services are building blocks that facilitate thecreation of e-business solutions. They are higher level application orientedcomponents that conform to the Framework's programming model. They buildon and extend the underlying application server software and networkinfrastructure with functions required for specific types of applications, forexample, e-commerce applications. As a result, e-business solutions can bedeveloped faster with higher quality. Examples of e-business applicationservices include payment services, catalog services, and order managementservices.

System managementWithin an enterprise, systems management services provide the corefunctionality that supports end to end management across networks,systems, middle ware and applications. The Framework provides the toolsand services that support management of the complete life cycle of anapplication from installation and configuration, to the monitoring of itsoperational characteristics such as availability and security, to the controlledupdate of changes. Across multiple enterprises, the Framework provides acollaborative management approach for establishing and followingprocedures to share information and coordinate problem resolution withbusiness partners. This collaborative approach includes policy management,data repository, scheduling and report generation.

Development toolsThe Framework provides a broad range of tools to enable creation,deployment and management of e-business applications for Internet, extranetand intranet environments. It also supports integrating third party tools intothe development process. The Framework supports the different skill sets


involved in developing Web applications, providing tools that target specificskill sets, and facilitates collaboration among members of the developmentteam.

API and protocols supportTable 2 through Table 7 summarize the standard protocols and APIssupported by each component of the Application Framework for e-business.While IBM will provide a complete and competitive set of products thatimplement the Framework, other implementations can also work within it.Thus, customers can choose from providers that support these openstandards. Likewise, solution providers can build their solutions using avariety of differently sourced software products. We deliberately omitted toinclude 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

Table 3. Standard protocols and APIs: Application server software

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


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


Table 4. Standard protocols and APIs: Web application environment

Table 5. Standard protocols and APIs: System management

Table 6. Standard protocols and APIs: Development tools

Table 7. Standard protocols and APIs: e-business application services

2.2.2.2 The programming modelWeb applications are applications that leverage Web clients (such as Webbrowsers), Web application servers, and standard Internet protocols. Theyalso typically leverage existing applications and data from external non-Webservices. Figure 11 illustrates the major elements of the Web applicationtopology supported by the Framework. It is important to note that the Webapplication server and external services are logical tiers capable of running

Workflow CORBA, WfM/IIOP, WfMC non applicable


Web server HTTP, HTML Servlets,Server-side-includes

Web browser HTTP, HTML Applets

Component model CORBA IIOP Java beans

Business componentmodel

CORBA IIOP JB, RMI

Scripting ECMAScript JSP


Distribution (Install/Config) DMTF-CIM AMS

Operations (Fix/Change) DMTF-CIM AMS

Performance (Monitor) SNMP ARM

Events (Alarms) SNMP TEC


Authoring and versioning WebDAV non applicable


Commerce EDI, OBI,SET non applicable



on the same physical machine. In addition, functionality on the Webapplication server can be spread across multiple physical machines.Frequently, the front-end and business logic parts of a Web application arerun on separate server machines.

Figure 11. WEB application topology

The application programming model defines application topologies andsolutions using the services defined by the Framework as described insection 2.2.2.1, “Application Framework Architecture” on page 44. For themost 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 applicationservers (using Internet standards, such as TCP/IP, HTTP, and HTML) toaccess business logic and data. The primary role of the client is to acceptand validate user input, and to present results received from the Webapplication server to the user.

Infrastructure services

These provide the Web application server and its business logiccomponents with directory and security services. Included in theseservices are firewalls that shield an organization's network from exposurewhen connecting to the Internet and prevent hackers and others fromgaining unauthorized access to internal data and computing resources.

Web application servers

These are the hubs of the Web application topology processing requestsfrom clients by orchestrating access to business logic and data on theserver and returning Web pages composed of static and dynamic content

c lie n tsW e b A p p lica tio nS e rve rs

E xte rn a l S e rv ices- in te r e n tre p rise s

- bus ines s pa rtne rsc lie n ts

Fire

wal

l


back to the client. The Web application server provides a wide range ofprogramming, data access, and application integration services for writingthe business logic part of a Web application.

External services

These consist of existing mission-critical applications and data within theenterprise as well as external partner services, such as payment services,financial services, and external information services. Most often, theseexisting applications and services control the company's core businessprocesses.

Most often, these existing applications and services control the company'score business processes.

2.2.3 Patterns for e-businessPatterns for e-business are a group of proven, reusable assets that can helpspeed the process of developing applications.The patterns are targeted tomeet 80% of the most common customer requirements. If you use thepatterns within a structured development methodology, you can extend theirscope to meet 100% of your requirements.

The patterns are a group of reusable assets, such as:

• Business patterns that identify the interaction between users andbusinesses.

• Logical patterns or topologies to define the existing customer environmentand 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 otherI/T architect presented with a customer problem can use this approach as anaid in helping the customer design and build an e-business solution. Usingthe patterns saves the architect from starting with a blank sheet of paper andallows guidance in reusing e-business assets. This approach makes the useof Application Framework for e-business products and technologies trulysimple and prescriptive, as shown in Figure 12.


Figure 12. Using Application Framework for e-business: a simple approach

Patterns for e-business describe the interaction between the participants inan 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-onlinebuying (where packaged goods are sold through a catalog using ashopping cart, a wallet, and so forth).

• User-to-online buying: Packaged goods are sold through a catalog usinga shopping cart, electronic wallet, or similar software tools. Thepurchasers may be consumers obtaining products or online buyerspurchasing goods from a supplier.

BUILD RUN MANAGE

Open standard, technologiesWindows 2000 Linux AIX Solaris OS/2 HP-UX OS/400 OS/390

Application Frameworkfor e-business

e-business

Development toolsand Components

Server andintegration software

Secure network andmanagement software

Physical pattern:- runtime product map

Business patterns:- based on scenarii

Customized customer solutions:= e-buisness solutions(CRM,SCM,KM,BI, e-commerce)

Customer expectation:- Business problem- Business procedures/rules- Existing environment

Methodology

Cus

tom

izat

ion

Logical patterns:- Application topologies- Runtime topologies


• Business-to-business: Programmatic links for inter-business tobusiness, 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. Thisincludes Business Intelligence and Knowledge Management. Example:evaluation of user purchasing preferences.

• User-to-user: Users collaborate with one another through e-mail, shareddocuments, and so forth. Example: collaboration across teams ondocument development.

• Application integration is required to speed the flow of data betweenexisting heterogeneous applications. It also programmatic links forintra-business to business.

Table 8 shows the relationship between some e-business solution areas andthe patterns for e-business introduced above.

Table 8. A pattern for each e-business solution

The inter- or intra-connection of patterns for e-business enables two or moreapplications to solve a business problem — for example, integratinguser-to-business with user-to-data to improve the personalization of acustomer self-help Web site.

There are two sets of logical patterns associated with each e-businesspattern:

• Application topology: The application topologies illustrate various waysthat the interaction between users, applications, and data can beconfigured.

• Runtime topology: The runtime topology uses nodes to group functionalrequirements. The nodes are interconnected to solve the business

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 Application integration


problem. Your choice of application topology will typically take you to theunderpinning runtime topology. The runtime topologies are based on theEnterprise Solution Structure (ESS) patterns. Some recent ESS workinvolved looking at patterns for complete end-to-end System Architectures(refer to the IBM Systems Journal, Volume 38, No. 1, 1999. EnterpriseSolutions Structure at http://www.research.ibm.com/journal/sj38-1.html).ESS is now part of SIMeth (or IBM Global Services Method), the workproduct based methodology used by IBM Global Services.

The physical patterns provide runtime product mappings together withguidelines for design, development and management of the application.

The rest of this section focuses on the business patterns. The logical andphysical patterns will be covered in more detail in Chapter 4, “Patterns forB2C and B2B applications” on page 107.

2.2.3.1 User-to-business patternThe user-to-business pattern refers to the general case of users (internal tothe enterprise or external) interacting with enterprise transactions and data.In particular, it is relevant to those enterprises that deal with goods andservices not normally listed in and sold from a catalog. Basically, it covers alluser-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 aneed to access back-end applications and data such as CustomerRelationship 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

- Portfolio summary- Detailed holdings- Transaction history- Quotes and news- Buy and sell stocks


2.2.3.2 User-to-online buying patternThe user-to-online buying pattern describes a special case (a subset of theuser-to-business pattern) where packaged goods, for example, are soldthrough a catalog using a shopping cart, a wallet, and so on. This includesboth consumers purchasing goods or online buyers purchasing goods from asingle supplier. It can also links to back end systems to allow for inventoryupdates and credit checking.

All e-commerce applications can be built on this model. Here are twoexamples of the user-to-online buying pattern: Consumers purchasing goodsonline; and buyers purchasing goods online from a supplier.

2.2.3.3 Business-to-business patternThe business-to-business pattern includes two styles of inter-business tobusiness. Intra-business to business is covered under the applicationintegration pattern.

The first style covers the programmatic link between arms-length business,where potentially a trading partner agreement may be appropriate. A goodexample of this would be the supply chain management (SCM) application.

The second style covers the eMarketPlace, where the model supportsB2M2B. The M represents the eMarketPlace, which supports multiple buyersand suppliers. The buying function may be performed online orprogrammatically.

2.2.3.4 User-to-data patternThe user-to-data pattern encompasses the provision of Business Intelligence(BI) capabilities to an organization. The user is someone connected to thedata 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 theuser-to-data scenario, while the user actually connected to the data is aninternal staff member or agent. For example, a customer phones a queryinto an organization and a staff member connects to a data store torespond to the query. In this scenario, the user is defined as the staffmember, not the customer.

• Intranet: a staff (internal) user

• Extranet or privileged Internet: an associate of the client’s organizationwho acts as a business agent on the company’s behalf.

• Fat client, connected as in a client-server system: applies to internal usersonly.


The data can be held in any of the following:

• Web-content store: holding Web pages and cached information. The datamay include copies of operational detailed records, such as consolidatedaccount information for a customer reference. The data is read-only; if anupdate of the data is required, the pattern is user-to-business, notuser-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, requirespecialized data stores for efficiency.

This pattern has several distinguishing characteristics:

• The user is not connecting to a traditional transactional system performingan operational business process.

• The user perceives themselves to be interacting directly with the datarather than with a system.

• Normally, the user has significant freedom and flexibility in her access ofavailable data. The data sets are often specially prepared in advance tosuit the user or the tool being used.

• The data sets being accessed:

- Are not the company’s prime operational data.

- Include a copy of relevant operational data and other data asnecessary.

- Include a historical set of data.

Application integrationLinking applications together within a business, like enterprise resourceplanning (ERP) with existing applications, is represented by the applicationintegration pattern. In particular, it is crucial to enable customers to installpackages which integrate with their existing systems. It is also required tosupport those applications which need to combine functionality from morethan one technology pattern, for example, a pharmaceutical company thatneeds stock transactions using WebSphere combined with access to patientrecords on Domino. This can be used within a business pattern or betweenbusiness patterns.


2.3 Summary

This chapter has provided a general overview of the IBM solution fore-business. This solution is built on a model that helps customers totransform and innovate their businesses to e-businesses — using the IBMApplication 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 IBMe-business world.


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

IBM’s goal is to be established as the leading provider of XML solutions tohelp solidify IBM's leadership position in e-business: XML is an e-businessaccelerator. This chapter describes the engagement and initiatives of IBM topromote XML up to its Application Framework for e-business. It lists, in anon-exhaustive manner, some tools and utilities IBM provides to developerson its AlphaWorks Web site. You will also find a short description of thecommitment of IBM toward standard frameworks, and overviews of XMLextensions of some IBM products.

3.1 e-business application with XML

IBM has joined open organizations such as OASIS, and XML.ORG (see3.3.1, “OASIS consortium, XML.ORG” on page 82) to accelerate the adoptionof e-business by establishing XML and associated industry specific grammarsas de facto industry standards. IBM also drives activities in W3C and othertrade organizations to leverage IBM product's integration of the standardsuch as DOM, and XSL.

IBM reinforces its Application Framework for e-business, as shown in Figure13, by extending its line of products with features which help customers andbusiness partners to build, deploy and manage e-business applications whichinterchange 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, andversioning).


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-businessapplication developed inside the Application Framework for e-businessemploy XML in these different purposes:

• Messaging

XML easily (compared to EDI) allows to use the same message format toexchange between organizations, or between application systems withinan organization. So with XML, the “threshold” for participating in amessage-exchanging community can be quite low.

• Rich document

With XML it is expected that richer document markup languages can bedefined. With a properly designed stylesheet, it should be relatively easyto design a personal markup language.

• Database

Many three-tier applications extract data from back-end databasesystems. Usually the results are transformed into the <table> tag of HTMLand displayed on the screen. If data is delivered as an XML document thatpreserves the original information, such as column names and data types,the data can be used by the client for purposes other than just displayingon the screen.

• Meta content

Because of its extensibility, flexibility, and readability, XML is considered tobe the best formalism to define a meta content syntax.

BUILD RUN MANAGE

Open standard, technologiesWindows 2000 Linux AIX Solaris OS/2 HP-UX OS/400 OS/390

Application Frameworkfor e-business

e-business

Development toolsand Components

Server andintegration software

Secure network andmanagement software

XML


Figure 14. XML in a Web application architecture

Table 9 through Table 13 are intended to place XML in the standard protocolsand APIs supported by each component of the Application Framework fore-business, as defined in “API and protocols support” on page 48.

Table 9. Standard protocols and APIs: Network infrastructure


Directory

Security XML-DSig IBM XML Security Suite

Network

File

Print

Pervasive computing WAP/WML, VoiceXML Not applicable

DTD/Schema

BrowsersandPervasive computing

XML dataXML meta data

XML:- data- meta data- messages

XML/XSLHTML/CSS

AppletsBeansActiveX components

XML/XSL

ServletsEJBsJSPs

XSL/XSLT

DatabaseStorage

MessagingData modelingMeta content

Rich document

Clients Web application servers Back-end

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

Table 10. Standard protocols and APIs: Application server software

Table 11. Standard protocols and APIs: Web application environment

Table 12. Standard protocols and APIs: Development tools

Table 13. Standard protocols and APIs: e-business application services

The next section provides additional information about IBM’s strategy to putXML in its Application Framework for e-business.


Mail and community

Groupware

Data XML, XQL, XPATH, SMIL DOM, JAXP

Transaction

Message queuing

Message routing,transformation

XML, XEDI MQSeries integrator

Workflow


Web server XML, XHTML, XSL/XSLT,XLink

Servlets,Server-side-includesJSP (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 componentmodel

XML EJB

Scripting


Authoring and versioning XML, XMI Not applicable


Commerce XML, TPA/BPF,RosanettaNet, ebXML

Not applicable


3.2 IBM XML development tools and utilities

To develop an application, programmers need some tools to be more efficientso they can avoid tedious tasks such as entering XML begin tags and endtags. They can find a plethora of useful tools and utilities on the IBMAlphaWorks Web site. These components are parcelled out in the IBMe-business application architecture, as depicted in Figure 15.

Figure 15. IBM XML components in the e-business application architecture

All the components to be described in this section are available from the IBMAlphaWorks site http://www.alphaworks.ibm.com or xml.apache.org. This list isnot exhaustive; there are other components on those sites, but we onlydescribe those which we thought were the most relevant.

XML enablerLotusXSL/XalanFOPXerces/SAXXML Is landSVGW ebSphere Transcoding Publisher

DB2 X ML ExtenderdomDirectXalan

M QSeriesIntegrator

DTD/Schema

BrowsersandPervasive computing

XML dataXML meta data

XML:- data- meta data- messages

XM L/XS LH TML/CS S

App letsBeansActiveX com ponents

XM L/XSL

ServletsEJB sJSP s

XSL/XSLT

DatabaseStorage

MessagingData m odelingMeta content

R ich docum ent

Clients W eb application servers Back-end


Table 14 lists the components by category, and gives the URLs from whichyou 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

XML4J Parsing /tech/xml4j

XML4C Parsing /tech/xml4c

Data Description byExample

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

Any software that is made available through AlphaWorks project is notgenerally available software. It has not undergone complete testing — itmay contain errors, or it may not function properly, and it is subject tochange or withdrawal at any time. No support or maintenance is providedwith the software. Do not install this software if you are not accustomed tousing experimental software. The AlphaWorks software is made availablewithout charge in the experimental stage in order to allow you to evaluatethe software in its development stage.

Note


3.2.1 Open source initiative: the xml.apache.org projectThe 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 inan open and cooperative fashion.

• Feedback to standards bodies (such as IETF and W3C) from animplementation perspective.

• A focus for XML-related activities within Apache projects.

The Apache Software Foundation (http://www.apache.org) exists to provideorganizational, legal, and financial support for the Apache open-sourcesoftware projects. Formerly known as the Apache Group, the Foundation hasbeen incorporated as a membership-based, not-for-profit corporation in order

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

Components Category Relative URL


to ensure that the Apache projects continue to exist beyond the participationof individual volunteers, to enable contributions of intellectual property andfunds on a sound basis, and to provide a vehicle for limiting legal exposurewhile participating in open-source software projects.

The xml.apache.org project began with a sizeable collection of open sourcesoftware to offer, donated by Sun and various other companies and individualdevelopers besides IBM. In fact, IBM is an Apache devotee, and has aproprietary version of Apache, a secure server called the IBM HTTP Serverpowered by Apache. IBM provided the initial code base for Xerces (Java,C++, and Perl versions), as well as ongoing support for this and other Apacheprojects such as the Apache HTTP server. Lotus provided the initial codebase for Xalan (Java and C++ versions).

The xml.apache.org project currently consists of four sub-projects, eachfocused 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 formattingobjects

• Xalan: XSL stylesheet processors

• Xerces: World-class XML parsers

Each of these sub-projects is described in more detail in the followingsections.

3.2.1.1 Cocoon — XML-based Web publishingCocoon is a powerful framework for XML Web publishing, written in Java,which brings a whole new world of abstraction and ease to consolidated Website creation and management based on the XML paradigm and relatedtechnologies.

The Cocoon model supports the creation of Web sites that are highlystructured and well-designed, reducing duplication of efforts and sitemanagement 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 differentcontexts. Cocoon facilitates better human resource management by givingeach individual a unique job, and reducing to a minimum the cross-talkbetween different working contexts.

To do this, the Cocoon model divides the development of Web content intothree separate levels:


• XML creation: The XML file is created by content owners with no specificknowledge of how the XML content is further processed, other than theparticular DTD/namespace chosen. This level is always performed byhumans directly through normal text editors or XML-aware tools/editors.

• XML processing: The requested XML file is processed and the logiccontained in its logic sheet is applied. Unlike other dynamic contentgenerators, the logic is separated from the content file.

• XSL rendering: The created document is then rendered by applying anXSL stylesheet to it and formatting it to the specified resource type (HTML,PDF, XML, WML, XHTML).

3.2.1.2 FOP — XSL formatting objectsFOP, 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 itinto a PDF document. The formatting object tree can be in the form of an XMLdocument (output by an XSLT engine like Xalan), or it can be passed inmemory as a DOM Document or (in the case of Xalan) as SAX events.

3.2.1.3 Xalan — XSL stylesheet processorsXalan (named after a rare musical instrument) is available for both Java andC++, fully implementing the W3C Recommendation 16 November 1999 XSLTransformations (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. Itincludes the XSL Transformation vocabulary and XPath, a language foraddressing parts of XML documents.

3.2.1.4 Xerces — XML parsersXerces (named after the Xerces Blue butterfly) provides world-class XMLparsing and generation. Fully-validating parsers are available for both Java(Xerces-J) and C++ (Xerces-C), implementing the W3C XML and DOM (Level1 and 2) standards, as well as the de facto SAX (version 2) standard. Theparsers 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 allowsaccess to a fully validating DOM XML parser from Perl. It also provides for fullaccess 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.


3.2.2 ParsersIBM is a pioneer in XML technologies, with parsers that have beenconsistently highly rated since XML4J version 1.0 was released in 1998. IBMis a major contributor to Apache's Xerces-J code base, which is the basis forXML4J version 3.

3.2.2.1 XML parser for JavaXML Parser for Java Early Access release (XML4J-EA) is based on theApache 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 classesand methods for parsing, generating, manipulating, and validating XMLdocuments. XML Parser for Java is believed to be the most robust XMLprocessor currently available and conforms most closely to the XML 1.0Recommendation.

XML4J includes support for DOM Level 2, SAX2 (alpha), and parts of W3CSchema.

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 Componentsfor Unicoded (ICU) and extends the number of encodings supported to over150.

It consists of three shared libraries (2 code and 1 data) which provide classesfor 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 APIdocumentation are provided with the parser.

XML4C is available on AIX, Linux, Solaris, Windows NT, Windows 98, HP-UX11, HP-UX 10.2, AS/400.

3.2.3 EditingAn XML document must be well-formed (tag balancing) and valid (respectDTD grammar). When creating a DTD file, or an XML document, it is quite


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 XMLdocuments, and DTDs.

3.2.3.1 Data Descriptions by ExampleData Descriptions by Example (DDbE) is a Java component library forinferring 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 thecontent models and the types used for attribute declarations. The goal ofDDbE is to give users a good start at creating DTDs for their ownapplications.

DDbE is available on all Java platforms.

3.2.3.2 TaskGuide ViewerTaskGuide Viewer is an XML-based tool for creating wizards. Thiswizard-creation tool makes computer tasks easier by breaking complicatedtasks 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 youbuild the graphical user interface and manage data using traditionalprogramming languages. Building and displaying wizards with the TaskGuideViewer is as easy as creating and viewing HTML files.

The companion documentation, IBM's TaskGuide: An XML-Based System forBuilding Wizards, has all the information you need to develop wizards. Onceyou've coded your wizard script, the TaskGuide Viewer displays your panelsand follows the instructions in your script. Best of all, the TaskGuide Viewerprovides usability-tested screen layout and navigation options, allowing youto focus on task content rather than design elements. The main headaches ofbuilding wizards like screen layout, navigation, and data management areeliminated.

TaskGuide is available on Java platforms.

3.2.3.3 Visual XML toolsThe IBM XML Tools package is an early technology release for providing XMLtooling in the Application Framework for e-business. It is not intended forproduction use. The IBM XML Tools can be enhanced via a series of ongoingupdates.

This package contains the following four Visual technologies:


1. Visual XML Query

Visual XML Query is a tool for helping you construct an XML queryexpression. 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 Queryengine.

- Save the XPath expression to a file.

2. Visual XML Builder

Visual XML Builder is a tool for constructing a valid XML document from aDTD. In particular, Visual XML Builder can be used to construct a TradingPartner 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 informationsuch 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 SQLquery. 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 queryresult. You can choose from a number of different patterns for mappingyour 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 thatprocesses this configuration file is included. You can deploy this servletto the WebSphere Application Server and use it to create XMLdocuments from an SQL query at run-time.

- Store a model using XMI.


4. Visual DTD

Visual DTD is a tool for creating and viewing DTDs. Using Visual DTD, youcan 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 forthe W3C XML Schema Language. IBM intends to provide completesupport 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 XMLdocument from existing XML documents. Transforming XML to XML canbe very useful if you want to take an existing XML format and transform itinto 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, andvisually construct the DTD describing the target XML document.

- Generate the resulting DTD.

- Generate the XSLT script that will transform the source XMLdocuments 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 XeenaWhen using Xeena, the editor takes as input a given Document TypeDefinition (DTD), and automatically builds a palette containing the elementsdefined in the DTD. Users can thus create/edit/expand any document derivedfrom that DTD, by using a visual tree-directed paradigm. The visual paradigm


requires a minimum learning curve, as only valid constructs/elements arepresented to the user in a context-sensitive palette.

A Key feature of Xeena is its syntax directed editing ability. Xeena is awareof the DTD grammar, and by making only authorized elements iconssensitive, automatically ensures that all documents generated are validaccording 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 checksvalidity of documents produced.

• Easy customization of display.

Xeena is available on Windows 95, Windows NT, Windows 98, UNIX, andMacOS.

3.2.3.5 XML Diff and MergeThe XML Diff and Merge Tool for XML is a Java program that can be used forreconciling or understanding changes that a single user has made to theirXML document, or for reconciling or understanding changes that severalpeople have made to a single document.

When using this tool, you pick one XML document to be the base and anotherone to compare it with. The tool points out each difference from the base byuse of symbols and color. You then walk through each difference and decidewhether to include the difference or not.

The XML merge tool is available on AIX and Windows NT.

3.2.3.6 X-ItX-It is a Java based application for batch processing of XML files. X-It takes abatch of XML files and processes/ transforms them based on the operationspecified.

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.


• 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 theresults and save; or in a non-interactive mode, which automatically saves thesuccessfully 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 MasterXML Master (XMas) allows you to design and generate custom Java Beansfor working with a particular XML document. It consists of two parts:

1. The XMas application — an editor for designing and generating customJava 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 formodeling XML structures and getting access to their parts viaXML-oriented GUI components.

The XMas application is used to design both visual and non-visual beans towork with a particular XML document, for example, select the XML elementsthat your application needs to work with and use the tool to design the layoutfor an editor to work with those elements. When the design is complete, usethe XMas application option to generate code. XMas creates the necessaryJava 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 EditorThis XSL stylesheet editor incorporates trace function and providesassistance with writing select and match expressions. It integrates XSL Tracewith the Visual Transform tool, both available on AlphaWorks.

IBM's XSL Editor allows users to set and remove “break points” on thestylesheet and source document. The XSL Editor user interface features anXML “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


automatically kept in synchronization with their corresponding tree views.Stylesheet authoring is made convenient by the ability to automaticallygenerate XPath syntax from sample source documents.

The XSL Editor is available on all Java platforms.

3.2.3.9 XSL TraceThe IBM XSL Trace application reveals the mystery of XSL transforms! XSLTrace allows a user to visually “step through” an XSL transformation script,highlighting the transformation rules as they are fired. Additionally, an XSLTrace user can view the XML source and the corresponding XML or HTMLresult in “real time”. XSL Trace users can set and remove “break points” onthe stylesheet and source document as well as highlight all source nodesprocessed by each style rule. The XSL Trace UI features an XML “sourcebased” collapsible “tree view” with dynamic font resizing for “Zooming” in/outto handle small/large documents.

The XSL Trace application is for anyone who is developing XSL scripts foreither 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 theLotusXSL and Advanced Internet Publishing Teams. As a consequence, XSLTrace adheres to the latest draft of the W3C XSL specification.

XSL can be a tough language for even experienced programmers to startusing. IBM's XSL Trace can speed up the creation of XSL scripts forseasoned developers and serve as a great learning tool for those new toXSL.

3.2.4 FormattingIn this section we describe some rendering technologies for displaying datacontained in XML documents through a Web browser.

3.2.4.1 DirectDOM Development KitThe DirectDom technology allows a Java developer to manipulate the liveDocument Object Model (W3C DOM) of a browser or Scalable VectorGraphics plug-in to build rich graphical user interfaces.

In its simplest form, DirectDom is about writing Weblets. These are Javaclient programs which use the client user interface facilities of a 5thgeneration browser or other DOM viewer (such as SVG) to render and controlits interface via standard W3C interfaces found in DOM Level 1, DOM Level2, and HTML 4.0. These DOM interface facilities include UI widgets, layout,accessibility, sound, and printing functions. Therefore, the Weblet runtime


does not rely upon the Abstract Windowing Toolkit (AWT) nor the JFC. TheDirectDom runtime is used to build Java programs which run inside a browserWeb page, or as stand alone applications.

The Weblet environment shall be dynamically reconfigurable and extensibleby means of a framework. This shall apply both to the Java component aswell as any possible native component of the Weblet runtime. Given thereliance of the Weblet runtime upon the underlying facilities of rapidlychanging browser technology, a Weblet environment provider must be able toupdate 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 HTMLand the logic in Java. In this case, one would embed a Weblet in an HTMLpage to perform a role, much as Java Script is used today. The role of theWeblet would be to set up event listeners to modifications of the HTML. Whensuch 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. Whenthe Weblet is started, it could dynamically add buttons, tables, text, andgraphics to the browser window via manipulating the DOM. As with the firstscenario, 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 attimes pre-constructed HTML is used for the user interface, while at othertimes 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 couldsimply run a Weblet directly by typing a command in a shell such as DOS orCSHELL or by double-clicking on a Weblet icon. In this case, the Webletcould then open a Weblet window to display a UI. A Weblet window is like anyother client OS window, and embeds a browser's engine inside it without theaccompanying browser chrome. The Weblet can then add UI elements to thiswindow by manipulating the DOM.

Of course, DirectDom Weblets can be used by non-Java programmers aswell. For example, an HTML author or Java Script developer could reusepre-existing Weblets to enhance a Web page or connect to a database.

The developer kit is available on Windows NT and 98 for Microsoft InternetExplorer 5.0+ (not including the IE 5.5 beta) and the Adobe SVG plug-in. ADevKit for Mozilla M14 (Windows NT, Windows 98, Mac OS 9, and Linux) willsoon be posted. The developer kit for DirectDom on Internet Explorer is


shipped in two forms, one that includes IBM's Java 1.2.2 JDK as well asDirectDom and one that includes only DirectDom.

3.2.4.2 LotusXSL XSL ProcessorXSL provides a mechanism for formatting and transforming XML, either at thebrowser or on the server. It allows the developer to take the abstract datasemantics of an XML instance and transform it into a presentation languagesuch as HTML.

LotusXSL implements an XSL processor in Java, and can interface to APIsthat conform to the October 1 Document Object Model (DOM) Level 1Specification. The processor can be used from the command line or from anwrapper applet, or it can be used as a sub module of other programs, andaccessed via the API.

LotusXSL version 0.20.0 is an IBM gold candidate preparing for a 1.0production-level release. It remains compatible with XML4J 2.x/1.x, as well aswith Xerces 1.0.2, and it is available on Java platforms.

3.2.4.3 SVGViewScalable Vector Graphics (SVG) is a language for describing two-dimensionalgraphics in XML. The language is a new standard being developed by theWorld Wide Web Consortium (W3C).

SVGView is a Java program that uses Java 2D and the XML Parser for Javato parse, process, and display SVG files on any XML-enabled Web browser.The viewer enables Web professionals working with SVG files to previewtheir forms or images. The viewer passes the document to the parser, whichcreates 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 asquare needs to be drawn, the relevant Java2D function draws the square atthe appropriate location.

For a demonstration of on-line transcoding, including Advanced FunctionPresentation (AFP) documents to SVG and Color Graphics Metafile (CGM)documents to SVG, see the IBM On-Line Transcoding Demo package. Youcan use SVGView to display the transcoded output.

SVGView is available on Windows 95, Windows NT, and Windows 98.

3.2.4.4 XML EnablerThe XML Enabler is a servlet that can successfully implement stylesheetssuch as the LotusXSL technology. Using the XML Enabler, developers withany kind of browser can now send requests to a servlet, and as the servlet


responds, it formats the data using different XSL stylesheets. The systemadministrator can then configure which stylesheets go with which browsertypes.

Therefore, the XML Enabler makes XML real by allowing any user of anybrowser to view and use XML data. Most developers in the XML space areconcerned with the heavy client. In other words, “you can use XML as soonas you move to Internet Explorer 4.0 or higher.” The XML Enabler technologyremoves this impediment and allows the system administrator to focus onusing XML-tagged data intelligently without worrying about the types ofbrowsers 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 administratordefines the mapping between browser types and XSL stylesheets. Once thatmapping is defined, the servlet gets XML data from a data source, thenformats 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 HTTPrequest comes in to the XML Enabler, it does three things:

1. Gets the XML document requested by the client (the URL of thatdocument 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 eachuser-agent type is defined by the Web master or Web mistress.

3. Once the XML document and the XSL stylesheet are selected, the two arecombined by the Lotus XSL Processor; the output from the XSL Processoris returned to the client.

XML Enabler is available on all Java platforms.

3.2.5 ProgrammingWhen programming an application, the developer needs to manipulate andaccess various types of data, and use pre-defined services such ascommunication services. This section describes some useful items whichcould help the developer.

3.2.5.1 Bean Markup LanguageBean Markup Language (BML) is an instance of an XML-based componentconfiguration or wiring language customized for the Java Bean componentmodel. The language is designed to be directly executable; that is,


processing a BML script will result in a running application configured asdescribed in the script. The BML language has elements that can be used todescribe the creation of new beans, accessing of existing beans,configuration of beans by setting/getting their properties and/or fields, bindingof events from some beans to other beans as well as calling of arbitrarymethods 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 arunning 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 intoreflection-free Java code. The advantage of this is that it allows one tocapture the inter-component structure of the application using a first-classlanguage 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 TSpacesTSpaces is a set of network communication buffers called “tuple spaces” anda set of APIs (and classes that implement the API) for accessing thosebuffers. TSpaces allows heterogeneous, Java-enabled devices to exchangedata with little programming effort. The package includes server software thatimplements 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 itssmall footprint, it is ideal for bringing network services to small andembedded systems; for example, it brings the power of the network to palmdevices, making them full-fledged network computers capable of controllingprinters and other networked devices.

For the client, being connected to TSpaces is like having the perfectassistant: TSpaces acts as a reminder service, carries out any tasks that youassign to it, reports incoming messages and delivers outgoing messages,and notifies you of any events in which you're interested. By adding additionalclient applications, TSpaces can be used as a universal print service, E-mailservice, pager service, remote control service, and so on.

TSpaces has many advantages over other technologies, including thefollowing:


• Data is de-coupled from programs. Data can outlive its producer (becauseonce it's produced, it lives in tuple space) and can be produced before thereceiver exists.

• Communication is anonymous. The sender needn't know about thereceiver, and vice-versa. Sender and receiver only need to know abouttuple space, which mediates all communication.

• Communication is asynchronous. The sender and receiver don't have torendezvous to communicate; the producer produces when it's ready, andthe consumer consumes when it's ready.

Since it is written in Java, TSpace client applications can be loadeddynamically into any network-attached computer. The TSpaces packagecomes with several useful applications that show how to build TSpace clients.

TSpaces is available on all Java platforms.

3.2.5.3 VoiceXMLVoiceXML is an XML-based markup language for distributed voiceapplications, much as HTML is a language for distributed visual applications.VoiceXML is designed for creating audio dialogs that feature synthesizedspeech, digitized audio, recognition of spoken and dual tone multi-frequency(DTMF) key input, recording of spoken input, telephony, and mixed-initiativeconversations. The goal is to provide voice access and interactive voiceresponse 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 topromote the Voice eXtensible Markup Language (VoiceXML).

VoiceXML brings the power of Web development and content delivery tovoice response applications, and frees the authors of such applications fromlow-level programming and resource management. It enables integration ofvoice 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 thebrowser implementation platform.

For further information on the VoiceXML Forum and to comment on thespecification, please refer to the VoiceXML Forum Web sitehttp://www.voicexml.org/.


3.2.5.4 XMI Tool KitXMI specifies an open information interchange model that gives developersworking with object technology the ability to exchange models and data overthe Internet in a standardized way, thus bringing consistency andcompatibility to applications created in collaborative environments. Byestablishing an industry standard for storing and sharing object programminginformation, development teams using various tools from multiple vendorscan collaborate on applications. The new XMI standard allows developers toleverage the Web to exchange data among tools, applications, andrepositories, to create secure, distributed applications built in a teamdevelopment environment.

The Toolkit is a Java component that converts UML information betweenRational Rose Models and XMI-standard XML files. The Toolkit can alsogenerate DTDs directly from your models. A Reference Implementation ofXMI, with source code, is included. The new functionality includes the abilityto generate Java from Rational Rose and UML models and to convert Java toRational Rose and UML models.

XMI toolkit is available on Windows 95, Windows NT, and Windows 98.

3.2.5.5 XML GeneratorCreating test cases for XML applications by hand from DTDs can be tediousand may not cover all possible or required instances. IBM's XML Generator isa Java program designed to automate this process by generating “random”instances of valid XML from a single input DTD. The XML Generator enginecan 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-definableconstraints, which lets the user limit the size and customize the appearanceof the output XML. Users can limit the depth of the generated tree, limit thenumber of IDs an IDREFs attribute can contain, choose whether or notimplied attributes should appear, and more. Users can even indicate whichentities 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 XMLapplications. DTD authors can also inspect “randomly” generated XMLinstances to quickly reveal “good and bad” DTD writing practices.

XML Generator is available on all Java platforms.


3.2.5.6 XML Lightweight ExtractorGiven a DTD, the XML Access Server Lightweight Extractor (XLE) allows auser to annotate the DTD to associate its various components with underlyingdata sources, and when requested, extracts data from the data sources andassembles the data into XML documents conforming to that DTD.

In many applications, it is often necessary to generate XML documents fromexisting 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, withoutrequiring 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 firstannotates the DTD file to create a mapping file called a DTDSA file.DTDSA annotation is done by inserting into the DTD file mappingconstructs that are syntactically simple yet flexible and powerful enough toexpress a large number of ways a user may want to map underlying datainto XML documents.

• When a particular XML document is requested, the user specifies theDTDSA file and zero or more runtime parameters, and XLE will constructthe appropriate XML document from the underlying data sources andreturn it to the user.

• The mapping mechanisms of DTDSA allow XLE to assemble an XMLdocument from a relational table, a set of relational tables related byforeign-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 SuiteXML is expected to facilitate Internet B2B messaging because of its simplicityand flexibility. One big concern that the customer may have in doing InternetB2B messaging is security. Internet is a public network, and there has beenno protection against attacks such as eavesdropping and forgery. Ifmessages are stolen or modified during transmission, B2B messaging couldbecome almost useless. Fortunately, the recent advancement of public-keycryptography has remedied most of the security problems in communication.Using modern cryptographic protocols such as SSL, the Internet became assecure as any other networks, including VANs and intranets.


IBM XML Security Suite will push the security further by introducing newsecurity features such as digital signature, element-wise encryption, andaccess control that are beyond the capability of the transport-level securityprotocol such as SSL. Our goal is to contribute to the discussions of standardbodies by providing sample implementations, as well as to supply ouradvanced technologies to our partners and to hear what they think. In thisrelease of XML Security Suite, IBM provides reference implementations ofDOMHASH, a proposed canonicalized digest value for XML documents, andits two sample applications. DOMHASH can be a basis for XML digitalsignature that is being discussed in both IETF and W3C.

IBM XML Security Suite is available on Linux, Windows 95, Windows NT, andWindows 98.

3.3 XML open frameworks

When interacting with business partners across open networks such as theInternet, there are likely to be considerable variations in request/responsetimes. In these cases, a single business flow requiring responsive interactionwith multiple partners, such as in the travel industry, will need to employparallel concurrent conversations. During these types of conversations,partners may detect unexpected conditions requiring specialized action bythe interaction or business logic software. An XML framework providesservices that map interaction events from message processing into businessevents which can be meaningfully handled in the business applications.These services enable the coupling of application processing to appropriateinteraction processing, with the ability to control how interaction events arefiltered and combined.

3.3.1 OASIS consortium, XML.ORGOASIS (http://www.oasis-open.org), the Organization for the Advancement ofStructured Information Standards, is a non-profit international consortiumfounded in 1993 to advance the open interchange of documents andstructured information objects. OASIS aims to accelerate the adoption ofproduct-independent formats based on public standards. These standardsinclude SGML, XML, HTML, and CGM, as well as others that are related tostructured information processing. Members of OASIS are providers, users,and specialists of the technologies that make these standards work inpractice.

XML.ORG (ww.xml.org) is an industry Web portal operated by OASIS, theOrganization for the Advancement of Structured Information Standards.


Funded by a group of companies committed to establishing an open,distributed system for enabling the use of XML in electronic commerce andother industrial applications, XML.ORG is designed to provide a crediblesource of accurate, timely information about the application of XML inindustrial and commercial settings and to serve as a reference repository forXML specifications. The most important function of XML.ORG is to serve as atrusted, secure, persistent repository and registry for document typedefinitions (DTDs), namespaces, schemas, and other specifications that mustbe globally accessible in order to make possible the use of XML for dataexchange within particular industries. This base functionality will evolvethrough releases offering increased capabilities to OASIS members and thegeneral public.

The reference site is intended to jump-start the use of XML for electroniccommerce by providing a key piece of the necessary infrastructure and thento serve as a model for an extensible, distributed system of registry/repositorysites based on the same architecture.

XML.ORG takes in an XML catalog which lists organizations known to beproducing industry-specific or cross-industry XML Specifications. The XMLCatalog is intended to evolve into the XML.ORG Registry and Repository forXML Schemas, DTDs, and specifications. Here are some initiatives forindustry 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


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 UnitedNations Centre for the Facilitation of Procedures and Practices forAdministration, Commerce and Transport (UN/CEFACT) and theOrganization for the Advancement of Structured Information Standards(OASIS) with a mandate to undertake a 15-18 month program of work. Thepurpose of ebXML initiative is to research and identify the technical basisupon which the global implementation of XML can be standardized. The goalis to provide an open technical framework to enable XML to be utilized in aconsistent and uniform manner for the exchange of Electronic Business (EB)data in application-to-application, application-to-human, andhuman-to-application environments, thus creating a single global market.

UN/CEFACT (http://www.unece.org/cefact) is the United Nations body whosemandate covers worldwide policy and technical development in the area oftrade facilitation and electronic business. Headquartered in Geneva, it hasdeveloped and promoted many tools for the facilitation of global businessprocesses, including UN/EDIFACT, the international EDI standard. Its currentwork 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 inebXML.

A primary objective of ebXML is to lower the barrier of entry to electronicbusiness in order to facilitate trade, particularly with respect to small- andmedium-sized enterprises (SMEs) and developing nations.

Following are some examples of ebXML’s value:

• Provides the only globally developed open XML-based Standard built on arich heritage of electronic business experience.

• Creates a Single Global Electronic Market Enables all parties irrespectiveof 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 investmentexpand 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 openprocess, ebXML delivers this value by:


• Developing technical specifications for the open ebXML infrastructure

• Creating the technical specifications with the world’s best experts

• Collaborating with other initiatives and standards developmentorganizations

• 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 ebXMLtechnical specifications

3.3.3 WebSphere B2B IntegratorIBM has announced WebSphere B2B Integrator software, which combinestechnologies from IBM's integration and transaction software, and which isbased on open XML technology.

WebSphere B2B Integrator is be built on IBM's WebSphere ApplicationServer, its industry-leading MQSeries messaging software and open XMLtechnology for e-contracts called tpaML (trading partner agreement markuplanguage).

The following sections supply a short overview of the fundamental buildingblocks on which WebSphere B2B Integrator will be based: Trading PartnerAgreements (TPAs) and the IBM Business-to-business Protocol Framework(BPF).

3.3.3.1 Trading Partner AgreementsWhen a business externalizes automated functions to make them available tobusiness partners several new issues must be addressed which were lessimportant or had simple solutions within a single enterprise. If the functionbecomes accessible via a public network, how will it be reached, who will beallowed to use it, and how will these users identify themselves? What do bothparties in the resulting long- running conversation commit to in terms ofbehavior, responsiveness and recovery from error situations? What are therules of interaction.

The foundation of tpaML is the Trading Partner Agreement (TPA). A TPA is anelectronic contract that uses XML to stipulate the general contract terms andconditions, participant roles (buyers and sellers), communication and securityprotocols, and business processes such as valid actions and sequencingrules.


tpaML is a complementary technology to business protocol standardsprojects such as ebXML, the Electronic Business XML initiative, which is ajoint effort of the United Nations/CEFACT and OASIS to establish a globalframework 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 byorganizing the information into separate functional layers. Data flow throughthe runtime layers is governed by specifications in the TPA. This layeringprovides appropriate abstractions for business data flow and minimizes theneed for specialized coding.

The functional layers specified in a TPA and supported in the underlyingBusiness-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, networkconnection, and basic security

• Document exchange, which provides document abstraction, includingmessage data mapping, non-repudiation, time-stamping, logging and audit

• Business protocol rules and interface, which defines the requests thateach partner may make of the other; and provides message sequence andresponsiveness checks, as well as document type and trading partnerspecific data handling.

These agreements are to be enforced by the customized integration softwarethat will be used to govern all transactions that are conducted over theInternet between the trading partners' business systems. For example,consider a small auto parts manufacturer that wants to sell to a major automaker. These two partners would take the following steps:

1. The auto maker creates the TPA using a TPA-aware authoring tool, thensends the parts manufacturer a tpaXML template containing all thenecessary information about the automaker.

2. The parts manufacturer adds the essential information about itself to thetemplate 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'ssite to customize the B2B integration software that will be installed oneach business system involved in transacting business.

4. At this point, the auto maker could issue purchase orders in the form ofXML documents transferred to the parts manufacturer under control of thetpaML document.


Section 6.2.1, “Trading Partner Agreements” on page 185 describes TPAs indetail.

3.3.3.2 Business-to-business Protocol Framework (BPF)The Business-to-business Protocol Framework (BPF) provides acomprehensive set of tools and enablers for ease of specification,configuration, plug-in, customization, and execution of a set of TPAs betweenbusiness partners. It is the gateway, coordinator and control-point of choiceacross intra-business and inter-business processes, for example, betweenthe buy/sell component of a local business, the remote businesses, and theback-end systems.

The protocols are expressed as an electronic TPA in XML using a higher levelauthoring tool and are registered to the BPF server along with the internalbusiness processes for setting up such B2B interactions.

BPF is architected as a general mechanism to support various businessprotocols 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 abusiness protocol, based on the specification of a protocol TPA. TypicallyB2B processes, such as Request For Quote (RFQ), Request For Information(RFI), and other processes, are similar across various B2B protocols and canbe implemented by the same framework. These other processes will beimplemented largely by changing the TPA. Tie-in to back-end systems isprovided by invoking an extensibility framework from the business logicinterface which is triggered by incoming requests.

A partner's use of BPF does not require that all partners to a given TPA mustalso use BPF. This independence is essential for doing business over anopen medium such as the Internet. One should not dictate to others whichtechnology to use to send and receive messages. Because BPF istechnology neutral, it is ideal for setting up loosely-coupled tradingagreements in which, for example, a business is free to replace suppliers byothers without having to make a large IT investment to support the newsupplier. As long as the business protocol, and hence the TPA, does notfundamentally change, replacing business partners by others is practical.

Figure 16 illustrates the role of BPF as the gateway, coordinator andcontrol-point of choice between intra-business and inter-business processes.It is positioned between the buy/sell component of a local business, theremote businesses, and the back-end systems. The applications spanning


multiple businesses (such as procurement or supply chain management) arenumerous and can be built using this framework.

Figure 16. BPF as a business-to-business coordinator

A version of BPF is built on top of an Enterprise Java Beans (EJB) server andemploys a diverse set of technologies for providing various functions andservices. A business may communicate with its partners using one of theseveral protocols HTTP, SMTP, FTP, VAN, IBM MQSeries. It may even usedifferent protocols for different sets of actions on a per-TPA basis. Securitytechnologies include transport security (SSL), authentication using digitalcertificates, 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 forconverting these documents into an internal format. Independent softwarecomponents providing many of these technologies can be plugged in to theBPF framework via a vendor-neutral open API, thus allowing developers tocustomize solutions of their choice.

B1

B2

B3

BPF BPF

purchasing selling

BackendSystems

BackendSystems


BPF provides many different services to the business applications running onthis platform. In addition to the basic TPA service, BPF provides services liketime-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 page204 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 andcross-platform technologies, meaning that you can confidently adopt newtechnologies such as XML, Java, and other component technologies thatenable you to move from business as usual to e-business.

IBM intends to XML-enable many middleware products to help customers andbusiness partners build, deploy and manage e-business applications. IBM isthe first to offer messaging products that support both XML and Javatechnologies. This functionality makes it easy for companies to exchangeinformation internally as well as with business partners and customers.format.

3.4.1 WebSphere Application ServersIBM WebSphere Application Servers (WASs) are part of a family of IBM Webapplication servers and complementary development and management toolsproviding a complete solution for running, building, and managing e-businessapplications. XML support and tools are key components of the serverenvironment, enabling widespread communication of business content.

3.4.1.1 WebSphere programming model with XMLWebSphere Standard Edition is capable of running servlets, Java Beans andJava Server Pages, all of which can connect to back-end resources such asdatabases. In addition to that, WebSphere Advanced Edition gives you theability to run Enterprise JavaBeans. Both editions provide a set of XMLrelated tools and utilities that are packaged into what is called XML DocumentStructure Services. These services consist of document parsers, documentvalidators, and document generators for server-side XML. The DocumentStructure Services support:

• W3C Extensible Markup Language (XML) 1.0

• W3C Namespaces in XML (Recommendation January 14, 1999)


• 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 threecomponents:

• XML for Java Parser

• LotusXSL

• DTD Catalogs

To make it easier to use industry standard DTDs and other grammars, localcopies are installed with the Application Server. Some of the grammars in thelibrary are:

• Channel Definition Format (CDF), developed by Microsoft Corporation,enables subscription to Web-based channels (a Web site or a portion of aWeb site). The subscription can be implemented to have the Web siteautomatically send the subscriber updates to the channel (using pushtechnology) or transmit the updates at the request of the subscriber (usingpull technology). In either case, the subscriber must be able to link to aCDF file on the channel site. The CDF file is an XML document thatconforms to the CDF DTD.

• Mathematics Markup Language (MathML), developed by the W3C, is agrammar for documents that contain math formulas, notations, and otherdata.

• Wireless Markup Language (WML) is a grammar for creating documentsso that they can be efficiently transmitted and displayed on narrowbanddevices, such as cellular phones, personal digital assistants (PDAs), andpagers.

XML is an excellent solution to separate data from its presentation, forexample, if you want to do any of the following:

• Tailor data to different client or media types:

- 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 otherapplications 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 inputparameters. Generally, these are used to generate HTML, which is then sentto a client browser over HTTP. However, servlets can generate any kind ofoutput stream, including XML. Servlets do not need to be called by a browser— other servers, Java programs, or Java Applets can call servlets over HTTPand receive XML data in this way. Because XML is easy to parse, and canform a publishable interface between systems, this is an easy mechanism forsystem-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 atruntime 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 arecompiled into servlets before running. This means that programmatically theyare equivalent to servlets. However, syntactically they are like HTML or XMLdocuments. Generally, JSPs have been used to generate HTML. However,


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 easierto create XML documents with JSPs. WebSphere Application Server 3.0supports this extension.

XSLT Islands are a new technology available inside WebSphere ApplicationServer version 3.0, which allows XSL to be used directly inside JSPs. Ineffect, this technology allows JSPs to contain HTML, Java and XSL in onefile. 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 XMLtechnology 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 XMLFiles: Using XML and XSL with IBM WebSphere 3.0, SG24-5479-00.

3.4.1.2 XML in the administration of WASWASs, servlets, and JSPs require a large amount of configuration data inorder to work properly. WebSphere takes advantage of XML to enforce theportability and the exchange of such data.

XML in EJBsXML can be used to create deployment descriptor for Enterprise Java Beans(EJBs). An XML file can be treated manually or by using a graphical userinterface (GUI) of the jetace tool. Once created, the XML file can be used togenerate 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 serversother than WAS, without having to manually enter the information by usingthe WAS administration console.

Configuring servlets using XML filesWhen WAS receives a request for a servlet instance, it can obtain the servletconfiguration from an XML servlet configuration file. That file contains all

In the EJB server environment, use of the XML features described here isnot recommended.

Note


required information such as the servlet initialization parameters, and thepage 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 forcalled JSPs. Moreover, if a referenced page has changed, you just update theXML configuration file instead of updating servlet code and recompiling theservlet.

Configuring WAS through XMLWAS includes an XML configuration management tool to import and exportconfiguration data to and from the WAS administration repository. That makeseffortless the cloning of WAS machines.

The XML documents must be coded to the WAS Configuration MarkupLanguage (WASCML) syntax.

The XML-based approach complements the administration tasks you canperform through the WAS administration console.

Configuring standalone servlet redirectorA standalone servlet redirector can be configured from data contained in anXML file. You need to customize the iiopredirector.xml file, which provideswhat would otherwise be command line arguments for starting the standaloneredirector and generating the Web server plug-in.

3.4.1.3 WebSphere DAV for JavaThe WebSphere DAV4J client API provides Java client applications with asimple, rich interface for accessing resources managed by a WebDAV server.Using this API, client applications are relieved from managing the details ofthe low level HTTP communication protocol, constructing and parsing XMLrequest and response entity bodies, and the complexities of the WebDAVsemantics. DAV4J also provides:

• A servlet that, with WebSphere application server, extends the ApacheWeb server with the WebDAV Class 2 protocol.

• Protocol independent (not just WebDAV) communication between clientand server applications, including support for http:, rmi:, and local access.Support for iiop: may be provided in a future release. Local access is usedif 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 2semantics that can interface with any WebDAV Class 2 compliant server.


• A Java servlet that along with WebSphere application server enables DAVClass 2 methods in the Apache Web server. The Apache Web server canbe configured so that some URLs can be handled either directly by theApache server without WebDAV methods while other URLs are handledby the DAV4J servlet with WebDAV methods. This allows a single Apacheserver to be both a production and authoring server on different partitionsof the URL namespace.

• The ability to access multiple back end repository managers using asingle, common, standard, simple protocol: WebDAV. The DAV4Jarchitecture encapsulates low-level repository services required toimplement the WebDAV semantics into a number of simple Javainterfaces. All that is required to provide WebDAV access to a repositorymanager is to implement these interfaces on the repository manager.DAV4J includes a repository manager based on the local file system as areference implementation and example of how to integrate a repositorymanager. There is also support for the NetObjects Authoring Serveravailable from NetObjects. Future releases may include support for therepository managers such as ClearCase from Rational.

• Platform independent, 100% pure Java portability.

DAV4J contains the IBM DAV4J client API, the DAV4J servlet, and the filesystem repository manager. By changing a few simple properties, theWebSphere application server can be configured to support the WebDAVmethods in the Apache Web server. WebDAV is described in the IETF draftspecification at http://www.ietf.org.

For further information, refer to http://www.alphaworks.ibm.com/tech/DAV4J.

3.4.1.4 WebSphere Transcoding PublisherOne key intermediary application is the transformation of information fromone form to another, a process called transcoding. Transcoding is alreadycommonly used in many applications to change data formats, for example toconvert a document from one word processor to another. The need fortranscoding is growing tremendously, as information on the Web becomesmore important and new ways are provided for people to access it.

For example, many Web pages contain large color images that cannot beviewed on palmtop computers, and XML data on the Web often needs to betransformed into other forms of XML or possibly into HTML before it can beviewed. business-to-business communication often requires information to betranscoded from the formats and structures specific to one company toformats and structures understood by business partners, suppliers, and


customers. Transcoders are specialized programs for transforminginformation into different forms.

IBM WebSphere Transcoding Publisher extends the reach of your data withan easy-to-use, flexible solution to the complex problem of bridging existingdata and applications to new environments. Transcoding Publisher isserver-side software that adapts, reformats, and filters data so that it isoptimally formatted for the destination environment, whether it be abusiness-to-business transaction, or an emerging pervasive computingdevice. Transcoding Publisher can be extended to deliver custom transformsin response to new breeds of devices, emerging XML variants, ande-business trends. The flexible architecture keeps the business ahead oftrends and ensures that your data and applications continue to reachcustomers 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-businesscommunications

• Tailoring host data that is already Web-enabled for the new breed ofpervasive devices

Features of Transcoding Publisher include:

• A set of basic content transformations or transcoders suitable formodifying Web data, such as HTML pages, GIF or JPEG images, and XMLdocuments.

• A robust framework that allows the Transcoding Technology to operate asa network intermediary (proxy), or WebSphere Application Server Servlet.Transcoders are also delivered as Java Beans, which can be utilized as anelement of a larger Web application development.

• A pluggable framework so that custom transformations work with existingones 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 profilesthat match a particular request

- Resolution of any conflicts between relevant profiles

- Selection of XSL stylesheets based on device and network type


- Configurations that allow preferences to be modified and plug-ins to beenabled 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 sitewww-4.ibm.com/software/webservers/transcoding.

3.4.2 VisualAge for JavaVisualAge for Java is an award-winning, integrated development environmentfor creating Web-enabled enterprise applications. It delivers the industry'smost advanced support for building, testing and deploying 100% Pure Javaapplications, JavaBeans components, servlets and applets. A key element ofIBM's Application Framework for e-business, VisualAge for Java allowsdevelopers to build Java applications for today's most demanding e-businessenvironments.

VisualAge for Java is equipped with a powerful suite of WebSphere tools.These tools enable you to use VisualAge for Java interactively with otherWebSphere products, such as WebSphere Studio and the WebSphereApplication 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 JavaConnectors, and can be emitted by using servlets, JavaServer Pages, orXML4J DOM. See 3.4.1.1, “WebSphere programming model with XML” onpage 89 for more information.

VisualAge for Java includes XML parsers (validating and non-validating) inthe project IBM XML Parser for Java.


3.4.3 MQSeries IntegratorMQSeries Integrator V2 exploits and complies with industry standards suchas Structured Query Language (SQL) and eXtensible Markup Language(XML), enabling different systems to share information and to directly supportemerging e-business standards. Integrator's ability to support XML, andbridge it to non-XML users as they migrate to XML, can accelerate thepenetration of supply chain e-commerce by reliably carrying transactionsbetween customers, suppliers, manufacturers, and finance organizations.

MQSeries offers more for the administrator of distributed applications. Withenhanced visual tooling combined with XML system message sets andassured delivery infrastructure, business systems can be deployed andmanaged in a manner that mirrors how an organization evolves and reflectshow its trading relationships evolve.

The MQSeries family can act as an XML gateway to B2C e-commerce. This isdone by converting between XML and legacy messaging formats that alreadyexist within an enterprise. Application servers such as WebSphere providethe gateway into the XML Internet world. This does not preclude the possibleapplication of MQSeries down to the client desktop, should it be required.MQSeries allows the integration of XML B2C e-commerce into a completeenterprise infrastructure which may be considerably more complex than3-tier.

In B2B transactions, the MQSeries family can integrate and coordinate notonly XML based ED, but also existing formats and protocols. This can useboth the Internet and intranets. Existing EDI protocols will not disappearovernight and be replaced with the brave new world of XML. Rather, there willbe different flavors of XML adopted by different industries. MQSeries allowsthe evolution in EDI messaging standards to be managed.

3.4.4 DB2 XML ExtenderThe IBM DB2 Extender family provides data and metadata managementsolutions to handle traditional and nontraditional data. The XML Extenderhelps 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, youcan combine structured XML information with your traditional relational data.Based on the application, you can choose whether to store entire XMLdocuments in DB2 as a nontraditional user-defined data type, or you can mapthe XML content as traditional data in relational tables. For nontraditionalXML data types, the XML Extender adds the power to search rich data types


of XML element or attribute values, in addition to the structural text searchthat the DB2 UDB Text Extender provides. Figure 17 shows a generaloverview of how the different components interact with each other.

Traditional SQL data is either decomposed from incoming XML documents orused to compose outgoing XML documents. The XML Extender providesapplication-specific mapping mechanisms to allow transformation betweenXML documents and relational data. The transformation includesdecomposing an XML document into one or more pieces and storing them inthe form of relational data, as well as composing XML documents from thedata in existing relational tables.

You specify how structured XML documents are to be stored or created in adocument access definition (DAD). The DAD itself is an XML formatteddocument. It associates XML documents to a DB2 database through twomajor access and storage methods: XML columns and XML collections. AnXML column contains intact XML documents. An XML collection is a set ofrelational tables containing data that is mapped to an XML document and thatcan be composed into an XML document.

Figure 17. DB2 XML Extender overview

Application

DB2 XMLExtender

StructuralSearch Eng.

Data Link

File System

XMLDOC

index

XM L Admin.Tool

Data AccessDefin ition

(DAD)

XM L Repository

DB2

table

XML docCLOB


The XML Extender provides several user-defined types (UDTs) for use withXML columns. A UDT is a data type that is not native to the databasemanager and is created by a user. All the XML Extender's UDTs have theprefix 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 inthe application table. The XML Extender supports legacy flat files; you are notrequired to store XML documents inside DB2. You can also store XMLdocuments as files on the local file system or remote file system, as specifiedby a local file name.

The DB2 XML Extender provides powerful user-defined functions (UDFs) tostore and retrieve XML documents in XML columns, as well as to extract XMLelement or attribute values. A UDF is a function that is defined to thedatabase management system and can be referenced thereafter in SQLqueries. All the XML Extender's UDFs have the prefix db2xml, which is theschema name of the DB2 XML Extender UDFs. The UDFs are applied to XMLUDTs, 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, eitherinternally or externally as a local file, while extracting desired XMLelement or attribute values into side tables for search.

• Compose or decompose contents of XML documents from or into an XMLcollection, which consists of one or more relational tables.

• Perform fast search on XML elements or attributes of SQL general datatypes by converting character strings in XML documents to SQL datatypes 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 isenabled for XML, a DTD reference table (DTD_REF) is created. Each row ofthis table represents a DTD with additional metadata information. Users canaccess this table to insert their own DTDs. The DTDs in the DTD_REF tableare used to validate XML documents and to help applications define a DAD.


For a Web publishing or Internet information portal solution, the application ortool builder may want to store Extensible Markup Language (XML)documents in DB2 and use SQL to do fast and powerful searches againstthem.

For e-commerce and other application integration solutions using XMLdocuments as their interchange format, application builders may want todecompose the XML document and map the data into relational tables orretrieve relational data and compose it into XML documents. You can easilydo this using the XML Parser for Java (included with DB2). the XML Extenderprovides wizards to help map XML Document Type Definitions (DTDs) torelational tables. The XML Extender also let you generate XML documentsfrom DB2 tables.

3.4.5 Lotus with XMLLotus recognized the value of XML very early, driving the development of XMLstandards through its active participation in World Wide Web Consortiumactivities, such as the XML Schemas and Extensible Stylesheet Languageworking groups. Lotus has also supported the XML community through itsdevelopment of LotusXSL, an open source, Java implementation of XSLTransforms.

3.4.5.1 Domino application serverThe Domino application server takes advantage of and exploits the capabilities ofXML and its related technologies. The design center of both Domino and XML isthe separation of data from document structure, delivering maximum flexibility indata manipulation and presentation.

Domino Java servlet and agent support make it easy to write business logicthat imports or produces XML. Domino forms and views provide anon-programmatic way to create XML from Domino data, using DominoDesigner. Domino R5 includes a set of Java design elements (views, outlinesand actions) that are populated via XML.

Domino Java servlets or agents can invoke the LotusXSL processor. LotusSXLprocessor provides the transformation functionality of Extensible StylesheetLanguage (XSL). XSL stylesheets are used to transform XML from one format toanother; or to transform XML to HTML for rendering in browsers and otherdevices.

Lotus also defined Domino XML Language (DXL) to express Domino data inXML. With DXL, user can export, import, or modify data as depicted in Figure18.


Figure 18. Lotus Domino XML language opens Domino data

Lotus will continue to enhance the Domino Application Server to helpcustomer be more productive when working with XML. New features andcorresponding benefits will include the following:

• Simplified development. New features will automatically retrieve Dominoview and document information in XML format, using standard HTTPprotocols.

• Integration with standard XML Tools: Lotus will provide a standard XMLDocument Type Definition (DTD) that describes the XML representation ofa Domino database, enabling automatic Domino import and export of bothdesign and data, using standard XML tools.

• Native storage of XML. Domino will store XML natively, augmenting itwith proven security and replication. The Domino database will optimizeXML storage for fast, efficient access.

• Runtime API support for Standard XML Libraries. Domino will include aset of standard APIs for XML, based on the DOM (Document ObjectModel) Level 1 and SAX (Simple API to XML), enhancing our currentobject model with an additional, standards-based API to Domino data.Language bindings to these APIs will be available in all currentlysupported languages, including LotusScript, COM, and Java, empoweringa broad set of developers to leverage the Domino platform using theirexisting tools and skills.

DXLNSF

XSLT

XSL

XM L orH TM L

Dom inoDom ino

The W orld

M odifications


• Easy access to the tools developers need. Lotus will include XMLParsers (the software component that interprets XML tags for processing)and the LotusXSL processor (a component that maps XML betweendiffering XML schema, or to HTML or SGML) in the rich set of standardtools on the Domino Server.

3.4.5.2 Notes clientThe 5.02 Notes client also includes DXL; an XML vocabulary for Domino; anda "readView entries" URL, which exposes NSF files to XML. DXL captures theexact content of a Domino database, and is accessible through HTTP andDomino/Notes APIs.

3.4.5.3 Domino designerDomino Designer provides a medium for writing XML and then serving theXML data to a parser. Domino Designer is a powerful developmentenvironment 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-SiteTivoli Cross-Site is an integrated suite of collaborative managementapplications designed to help organizations manage their mission-criticale-business activities. This is accomplished through the combination of one ormore Tivoli Cross-Site management servers communicating with other TivoliCross-Site management servers and Tivoli Cross-Site managed clients oversecure, Web-based transport protocols as shown in Figure 19.


Figure 19. Tivoli Cross-Site architecture

The management server is the Tivoli Cross-Site server-based component thatcomprises core services and management application elements. Themanagement server consolidates and stores information from managedclients or other management servers. In addition, it initiates operations onmanaged resources in the Tivoli Cross-Site environment.

The managed client is the Tivoli Cross-Site client-based component thatcomprises core services and management application elements. Managedclients monitor resources, collect information, and perform tasks locally.Managed clients transfer information from and send events to managementservers. 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 managementservers. Communication between managed clients and management serversuses HTTP and HTTPS, which is HTTP running over Secure Sockets Layer(SSL). Managed clients send messages encoded in Extensible MarkupLanguage (XML) to management servers. Managed clients can communicatewith management servers locally at the same site or remotely over theInternet.

ManagementServer

ManagementServer

ManagementServer

AppClient

AppClient

AppClient

Client core services

XML specifications

HTTP

SSL

Managed Clients

AppClient

AppClient

AppClient

Client core services

XML specifications

HTTP

SSL

Managed Clients

AppServer

AppServer

AppServer

Server coreservices

XML specifications

HTTP

SSL

Management Servers

InternetISP ISP

ManagementConsole

RDBMS

HTTPServer


3.5 Summary

This chapter demonstrated the engagement of IBM in XML technology, andits commitment to the XML standards. It also described tools and productsthat IBM develops to help customers to design, develop, and deploye-business applications.


Part 2. Designing B2C and B2B e-business applications using XML

This part of the book describes business-to-customer (B2C) andbusiness-to-business (B2B) e-business models in detail, concentratingon the role of XML during the design and implementation of these typesof applications. It is for intended for people who are involved in thedesign of these applications, to help them understand the e-businessarchitecture, technology choices, and design issues related to XMLadaptation.

Chapter 4, “Patterns for B2C and B2B applications” on page 107introduces the common architectural concepts in this kind ofe-business applications, including a detailed architecture andapplication of XML technologies. We also cover general design issuesrelated to XML fields like design, performance, and security.

Chapter 5, “B2C applications using XML” on page 139 explains thedetails of business-to-consumer applications. It gives a detaileddescription of customer services, enterprise portals, andpersonalization based on the XML technology and the IBM productofferings. We present an outline solution and application examplebased on the WebSphere product family to build business-to-consumerapplications.

Chapter 6, “B2B applications using XML” on page 177 deals withbusiness-to-business applications, and shows the role that XML canplay in this particular application context. Business-to-business ispositioned as one of the best opportunities of the emerging businessintegration IT challenge for the coming years, and what IBM is doing tohelp companies in this field is presented. The standard proposal of theTrading Partners Agreement Markup Language (tpaML) and theBusiness-to-business Protocol Framework (BPF), both proposed byIBM, are described in detail. These technologies are the basic buildingblocks of IBM WebSphere B2B Integrator, the B2B XML-basedframework announced by IBM. At the end of the chapter we offer anoutline solution to build Trading Partners Agreements by using the IBMXML Visual Builder tool.


Chapter 4. Patterns for B2C and B2B applications

In this chapter, we introduce the two classes of applications this book isdealing with, namely, business-to-consumer (B2C) and business-to-business(B2B) applications, as described in 1.1.3.2, “Inter-business applications” onpage 11. Then we cover established patterns for general businessapplications, 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 canbe used to develop inter-business applications, covered in 1.1.3, “A simplifiedclassification schema for e-business applications” on page 8. We canassociate these business patterns with both classes of e-businessapplications: the user-to-business and user-to-online buying patterns areapplicable for business-to-consumer (B2C) applications, while thebusiness-to-business pattern obviously is for business-to-business (B2B)applications.

We also extract the logical patterns (application and runtime topologies) andphysical patterns (product mappings) from the Patterns for e-business Website for B2B, and document some draft proposed B2B patterns which willappear on the Web site in the future. Finally, we consider the place of XMLtechnology in B2C and B2B applications, covering general design issuesrelated 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-businesspatterns for B2C applications” on page 110, and 4.3, “e-business patterns forB2B applications” on page 117.

4.1.1 Logical and physical patternsAt this point we recall the logical and physical patterns already discussed in2.2.3, “Patterns for e-business” on page 51.

The Patterns for e-business aim to communicate in a highly accessiblefashion the business pattern, systems architecture (application and runtimetopologies), and product mappings required for different classes ofapplications. They are particularly focused upon addressing commonbusiness application problems and providing answers to frequentarchitecture, design, and implementation questions.


Patterns for e-business can be used in a number of ways, according to yourneeds:

• As a starting point for an end-to-end system architecture

• As a detailed example and prescriptive approach, following the productmappings and guidance provided

• As a way to design more complex, multi-channel systems, when severalpatterns are used together

The application topologies use logical nodes to illustrate various ways toconfigure the interaction between users, applications, and data. The chosenapplication topology is later mapped to a runtime topology by mapping thelogical nodes to runtime nodes. An application topology shows the principallayout of the application, focusing on the shape of the application, theapplication logic, and the associated data. It does not show middleware or thefiles or databases where Web pages may be stored.

The runtime topologies use nodes to group functional and operationalcomponents. The nodes are interconnected to solve a business problem.

The physical patterns provide runtime product mappings together withguidelines for the design, development and management of the application.

4.1.2 Runtime topology nodesThis section gives a short description of the functional nodes broadly usedwhen we explain the runtime topologies in 4.2, “e-business patterns for B2Capplications” on page 110, and 4.3, “e-business patterns for B2Bapplications” on page 117.

Database server node provides a persistent data storage and retrievalservice in support of the user-to-business transactional interaction. The datastored is relevant to the specific business interaction, for example, bankbalance, 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 andcertificates) 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 securityprocessing, for example, to verify certificates. The authentication in mostcurrent designs validates the access to the Web application server part of theWeb server, but it can also authenticate for access to the database server.


Domain name server (DNS) node assists in determining the physicalnetwork address associated with the symbolic address (URL) of therequested information. The DNS on the node diagram is that of the Internetservice provider, although DNS is implemented on the accessed site also.

Existing application and data nodes include all existing applicationsrunning and maintained on nodes which are installed in the internal network.These applications provide for business logic that uses data maintained in theinternal network. The number and topology of these existing application anddata nodes is dependent on the particular configuration used by these legacysystems.

Protocol firewall and domain firewall nodes provide services which can beused 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 theexpense of increasing computing resource requirements. The protocolfirewall is typically implemented as an IP Router, while the domain firewall asa dedicated server node.

Public key infrastructure (PKI) is a collection of standards basedtechnologies and commercial services to support the secure interaction oftwo unrelated entities over the Internet such as public user and corporate.Public key infrastructure (PKI) in the context of runtime topologies, supportsthe authentication of one distributed applications to another using the SSLprotocol.

User node is most frequently a personal computing device, such as a PC,supporting a commercial browser, for example, Netscape Navigator, orInternet Explorer. The level of the browser is expected to support SSL andsome level of DHTML. Increasingly, designers should also consider that thisnode may be a pervasive computing device, such as a PDA.

Virtual private network (VPN) node is an extension of an enterprise'sprivate Internet across the Internet, or other public network. It creates asecure private “tunnel” through the Internet to the other partner.

Web application server node is an application server that includes an HTTPserver (also known as a Web Server) and is typically designed for access byHTTP clients and to host both presentation and business logic.

Chapter 4. Patterns for B2C and B2B applications 109

4.2 e-business patterns for B2C applications

This is, by far, the most common type of e-business application. Activities aredriven by the consumer and, usually, based around the Internet. Theconsumer is outside of the organization using the service. This service couldtake the form of goods or information. There is also widespread use of theterm Enterprise Portals to refer to the set of Web-based applications thatenable companies to connect customers to their information systems, andthat provide a single gateway to personalized information needed to makebusiness decisions. There are two patterns for e-business related to B2Capplications: user-to-business and user-to-online buying.

XML plays key roles in building business-to-customer applications: it is ahighly flexible data format with strong data description capabilities, itenhances delivery and representation, and it can be used as a standarddocument 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, paperor 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-customerapplications

As a document delivery technology, XML has these advantages:

• It integrates to client applications without the need for manual editing orpresentation transformation.

• It allows rich presentation formats that can be individually tailored tocustomer’s needs.

• Using XML, data can be processed at the client side controlled by thecustomer for maximum flexibility.


For a more complete coverage of user-to-business topologies, werecommend the IBM Redbook Patterns for e-business: User to BusinessPatterns for Topology 1 and 2 using WebSphere Advanced Edition,SG24-586400.

4.2.1 B2C logical patterns for e-businessThis section addresses the Web applications built from scratch, calledWeb-up applications. It concentrates on two of the Web-up specificapplication topologies for the user-to-business pattern:

• Topology 1, for use when no legacy or third-party applications arerequired.

• Topology 2, for use when the access to legacy and/or third-partyapplications is required.

Web-up is used to represent both an attitude of mind (Web-centric) and theconsequent implementation of new Web browser centric applications. Thedata may be acquired by replication from existing sources or typed in by newusers from the Web.

4.2.1.1 Web-up — topology 1This topology describes the situation where you are planning a newapplication or extending a current Web publishing capability, with ane-commerce capability and no back-end integration (a classic Web-upstrategy). For example, it allows businesses to provide consumers withread-only access to marketing and sales literature via the Web. Furthermore,consumers can make business transactions that update a database withinthe new application.

This topology is sufficient if you do not have any legacy or third party systemsto integrate with, or at least do not have this need at this point in time. Thistopology can be easily extended to topology 2 in the future to include accessto existing applications such as inventory management, or third partyapplications such as a credit check.

Application topologyFigure 20 outlines the application topology 1. In this topology, we replaces themonolithic fat client design with a layered approach. This architecture uses athin client with application business logic on the second tier. The second tiercan access a local database maintaining the application data. It aims toaddress the scalability problems of client/server and at the same time providereuse of the business logic and data by all styles of Web browsers orpervasive computing devices.


Figure 20. Application topology: Web-up topology 1

You should consider that a Web application server may implement both tiersof the layered design, but developers should exercise caution. Many vendorspromote ease of development by mixing scripting and components, payinglittle attention to engineering the application with separate presentation andbusiness logic layers. This combined approach should be avoided, asseparation 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 andextend. Also, be aware that you may incur significant departmental systemmanagement costs when the business logic and data are held outside the ITorganization.

Runtime topologyFor the Web-up application topology 1, more than one runtime topology arepossible. We chose to only explain the simplest one. Other runtimetopologies are well described in the IBM Redbook Patterns for e-business:User to Business Patterns for Topology 1 and 2 using WebSphere AdvancedEdition, SG24-5864-00.

The chosen runtime topology, shown in Figure 21, aims to provide an initialimplementation with an entry level footprint. Or, “Start simply, grow fast”.

T h in c lien t(P resen ta tion

log ic )

A pp lica tion(B us iness log ic )

sync

a n a p p lica tio n n o d e w h ich con ta in s n e w o rm o d ifie d com p o n en ts re ad /w rite da ta


Figure 21. Runtime topology: Web-up topology 1

This runtime topology is the most basic one you could associate with theapplication topology 1 of the Web-up model:

1. The Web application server (where the Web server and the applicationServer 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 inthe directory and security services node behind the domain firewall in theinternal network.

4. The data to be accessed from the business logic is behind the domainfirewall 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, inturn, has some consequences:

a. A load balancer is used to distribute the incoming requests to the Webapplication servers.

b. A shared file system may be installed in the internal network. This filesystem provides for shared access to information needed by all Webapplication servers.

2. Move the Web application server behind the DMZ to provide moresecurity. 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 domainfirewall where it is more secure.

D a ta b a seU s e r

P u b lic K eyIn fras tru c tu re

D o m a ineN am eS erv e r

INTERNET

D ire c to ry a ndS ec u r ityS e rv ic e s

O u ts id e w o rld D e m ilita riz e d Z o n e(D M Z )

In te rn a l n e tw o rk

Dom

ain

Fire

wal

l

Pro

toco

lFire

wal

l

W e bA p p lic a tio n

S erve r


c. Uses a Web server redirector to forward the requests from the Webserver to the application server.

3. Add an additional application server behind the DMZ to provide moresecurity. A Web application server within the DMZ is used for presentationlogic, but all business logic is implemented within the application serverbehind the DMZ.

4.2.1.2 Web-up — topology 2Application topology 2 allows for one or more point-to-point connections toback-end legacy applications or databases. This is a very commonrequirement for businesses delivering goods and services over the Web. Forexample, an e-commerce application can be integrated with existingback-end applications such as inventory management.

Often this topology is used to extend existing application topology 1 solutionsto integrate with legacy or third-party systems, for example, inventorymanagement or credit card checking.

Application topologyApplication topology 2 for user-to-business is shown in Figure 22. It allowsthe second tier’s new application business logic to access existingapplications or data, or third party applications. These applications reside ona third tier elsewhere in the network.

Figure 22. Application topology: Web-up topology 2

Application topology 2 has the same logical application nodes known fromapplication topology 1 and at least one additional node, making it a logical3-tier architecture. Depending on the requirements, this additional logicallayer contains new, modified, or unmodified components, and resides in thethird tier.

Application(Business logic)

App2sync sync/async

an application node which contains new ormodified componentsan application node which containsexisting components with no need for

modification or which cannot bechanged

App1

read/write data

Thin client(Presentation)


If the developer needs to provide access to many applications on the thirdtier, an advanced application topology may be more appropriate. You shouldconsider an application topology that exploits a hub-and-spoke architecturebetween the second and third tiers.

You should consider how this topology will be deployed to avoid systemsmanagement complexity. Complexity arises when updated corporate dataresides on more than one tier, with the second and third tiers both within thesame organization but physically distributed. For example, synchronization ofbackups may be cumbersome.

If there are different IT organizations developing the new application andmaintaining or changing the existing systems, the development might bedifficult to coordinate, especially if the interfaces between the new and theexisting systems are not properly defined and documented.

As stated before, the new application might require changes to existingproduction systems. This is always a critical task, especially when theback-end systems or third-party applications are mission critical. Anotherproblem might be in having skilled resources that can change the third tierapplication. Often these are quite old applications, and finding someone whounderstands them well enough to change them may be difficult.

Runtime topologyApplication topology 2 also can have more than one possible runtimetopology. We chose to only explain the simplest one shown on Figure 23. Thechosen runtime topology providing an extension of runtime topology 1 tointegrate legacy or third-party systems.

Figure 23. Runtime topology: Web-up topology 2

User

Public KeyInfrastructure

DomaineNameServer

INTERNET

WebApplication

Server

Directory andSecurityServices

Outside world Demilitarized Zone (DMZ) Internal network

Pro

toco

lFire

wal

l

Existingapplications

and data

Dom

ain

Fire

wal

l


This simple runtime topology suits the application topology 2 of the Web-upmodel:

1. The Web application server (where the Web server and the applicationserver are running on the same machine) is in the demilitarized zone(DMZ).

2. The business logic is implemented on both the Web application server andexisting applications in the internal network.

3. User information, needed for authentication and authorization, is stored inthe directory and security services node behind the domain firewall in theinternal network.

4. The existing applications and data to be accessed from the business logicare behind the domain firewall in the internal network.

This topology uses the same nodes as the runtime topology 1 excepted theexisting 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 Webapplication servers.

b. A shared file system may be installed in the internal network. This filesystem provides for shared access to information needed by all Webapplication servers.

2. You can move the Web application server behind the DMZ to provide moresecurity. 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 domainfirewall where it is more secure.

c. Uses a Web server redirector to forward the requests from the Webserver to the application server.

3. You can add an additional application server behind the DMZ to providemore security. A Web application server within the DMZ is used forpresentation logic, but all business logic is implemented within theapplication server behind the DMZ.


4.3 e-business patterns for B2B applications

These types of applications focus on using the Internet and/or extranet toimprove business-to-business partnerships and transforminter-organizational relationships. Companies can cut the cost of operationsand production, improve business processes, and deliver more value tomarket by leveraging e-business enhanced partnerships.

The benefits of XML involve the efficient use of data transfer. Inbusiness-to-business situations, there are several ways to communicatedata, but many still require some sort of reentry process. For example, youmight send a fax to a vendor stating you need to reorder a certain item or thata certain item needs to be sent directly to the customer. Once the fax isreceived, someone in that company and department may retype theinformation in their system in order to process the information. The problem isthat 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 whatthe data means and how it is presented (via XML markup). XML is thatstandard. Once both companies agreed to the information meaning and XMLmarkup, a parser can be created to easily move the data without having toreenter the data. The parser can even be so smart as to apply business rulesto manipulate the data pre- or post-transfer.

The concept of data transfer efficiency is not a new one. It has beenimplemented and re-implemented in most large organizations. The problem isthat because there was not a standard, most implementations are proprietary.XML removes the need to re-engineer the transfer process between thedifferent companies you deal with.

4.3.1 B2B logical patterns for e-businessThis section describes application and runtime topologies for five businessmodels covering most business-to-business applications:

• Document exchange

• Direct exchange with adaptor/bridge

• Message brokers

• Business protocol managed applications

• Jointly managed applications


4.3.1.1 Document exchangeTwo partners can use this topology to maximize the performance of theinteraction, 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 particularValue Added Network (VAN). A VAN is a networking service that leasescommunication lines to subscribers and adds extra services or capabilitysuch as security, error detection, guaranteed message delivery, and amessage buffer.

The application topology shown in Figure 24 represents the essential currentpractice in business-to-business interaction. Mutually agreed-uponmessages, such as EDI transaction sets, are exchanged via mechanisms thatallow the messages to be retrieved from a persistent buffer. The transmissionformat of the data is translated into a format usable by the internal businessprocesses of the receiving organization.

Figure 24. Application topology: document exchange

EDI is a well established standard, but it is deployed by only a small numberof companies. The need for flexibility in connecting to many partners, whomay have very different IT infrastructure capabilities, may make this topologyinappropriate for many businesses. It is most applicable to those that need toparticipate in an existing EDI-based network.

Figure 25 depicts the VAN-document runtime topology for the documentexchange model which represents the current practice for EDI interactionsbetween businesses. Message interactions are mediated by a VAN serviceprovider that delivers messages to mail boxes.

Translator App 21:1

async

available buffermutually agreed msgs

App 1 Translator

application node which contains newormodified components.

application node containing existingcomponents with no needfor modification or which cannot bechanged.

read/write storage unit


Figure 25. Runtime topology: VAN-document

Companies A and B have subscribed to a VAN. Users of a VAN sendmessages to and retrieve messages from a mailbox. This service of the VANholds messages until the receiver requests them. VAN access pointrepresents the networking endpoint of a VAN. It is the company's connectionto the VAN. In its simplest form, an EDI translator converts EDI transactionsets (EDI messages) to and from flat files of a format needed by anenterprise's applications.

4.3.1.2 Direct exchange with adapter/bridgeThis topology provides interaction with specific applications in a low complexcontext. It is applicable when a more sophisticated agreement between thepartners is not necessary, or when this interaction is a specialized case of alarger cooperation.

Figure 26 portrays a particular application topology available for use byoutside organizations. A message-based interaction is extended to include anadapter or bridge that converts the mutually agreed to messages into APIcalls to existing applications. In this way, an existing application can beintegrated across organizational boundaries. The types of interactions arelimited by the functions and restrictions embodied by this application.

ExistingApplications

and data

Internal network Managed network Internal network

VANMail box

EDItranslationpackage

EDItranslationpackage

ExistingApplications

and data

VA

Nac

cess

poin

t VAN

VANMail box

VA

Nac

cess

poin

t

Company A Company B


Figure 26. Application topology: Direct exchange with adapter/bridge

The message definitions should be made as general as possible in order topromote some flexibility in changing the interface of the application withoutaffecting the agreed-upon message definitions. Still, even with thisabstraction, this topology is not easily generalizable to a more sophisticatedintegration of business processes.

The connection of applications over message-oriented middleware isrepresented in the Internet Direct Queue runtime topology. The connectionbetween partners is by a secure Virtual Private Network (VPN) as shown inFigure 27.

Figure 27. Runtime topology: Internet direct queue

Messages are sent to and received from queues that are managed by aqueue manager. A queue manager provides a persistent message store andadditional services including transaction support, and routing of messages tothe proper queue. The receiver of a message can be an adapter that

App 2N:1

async

server-specified msgsadaptor (msgs to API)

App 1

INTERNET

Direc tory andSecurityServices

Ex is tingapp lica tio ns

and d ata

internal netw ork

D MZ : D em ilitarized Z one

Pro

toco

lFire

wal

l

Dom

ain

Fire

wal

l

Extranet

P ublic keyinfra stru cture

D om ain n am es erv er

C om pany A

VP

Nen

dpo

int

Q ueuem anager

DMZ

Direc tory a ndSecurityServices

Ex ist ingapp lications

and data

internal network

Q ueuem anager

DMZ

VP

Nen

dpo

int

Dom

ain

Fire

wal

l

Pro

toco

lFire

wal

l

Co mp any B


transforms the message data into parameters on method or procedure callsto 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 domainfire wall is also possible.

4.3.1.3 Message brokerMessage brokers and application adapters are common building blocks ofenterprise application integration. This topology leverages the investmentmade in application integration to extend beyond the enterprise.

The application topology shown in Figure 28, embodies the concept ofexposing applications or sets of applications to an outside organization as aset of services. Integral to this topology is a message broker that can routeand compose or decompose messages as appropriate for the application orapplications implementing a service, employing adapters as necessary. Thismaximizes both isolation of business processes from the outside organizationand the flexibility to change the processes and the applications thatimplement them.

Figure 28. Application topology: message broker

When enterprise integration approaches are extended outside of thecompany, additional problems must be addressed, including the enforcementof business-to-business protocols and specific agreements between thepartners.

App 21:1async

App 3comp/decomp

rulesN:1

asyncserver-specified msgs

adaptor

App 11:1

async

Partner Intermediate tier Corporate tier


Figure 29 illustrates the Internet brokered runtime topology supportingmessage-oriented interactions via message broker. This broker handlesenterprise application integration and communicates over a VPN.

Figure 29. Runtime topology: Internet brokered

A message broker is built on a queue manager and routes messages toapplications. A message broker can provide real-time, intelligent, rules-basedmessage routing and dynamic message content transformation andformatting. In this runtime topology, the message broker allows multipleapplications to implement a published service with the broker providingapplication integration.

A variation of this runtime topology could be to move both VPN end point andmessage broker behind the domain firewall node.

4.3.1.4 Business protocol managed applicationsThis topology maximizes flexibility while providing assurance that contractualagreements are being met. Like message broker topology, it leverages theinvestment 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 currentpractice in enterprise application integration.

The business protocol managed application topology, illustrated in Figure 30,combines the services and broker approach of the message broker topologywith management of the business protocol between the two trading partners.It includes an executable contract, agreed to by the trading partners, that

INTERNET



and data

internal network

DMZ: Demilitarized Zone

Pro

toco

lFire

wal

l

Dom

ain

Fire

wal

l

Extranet

Public keyinfrastructure

Domain nameserver

Company A

VP

Nen

dpo

int

Messagebroker

DMZ



and data

internal network

Messagebroker

DMZ

VP

Nen

dpo

int

Dom

ain

Fire

wal

l

Pro

toco

lFire

wal

l

Company B


mediates the business-to-business interactions. Implementations of serviceinterfaces use brokering to interact with internal business processes as inmessage broker topology.

Figure 30. Application topology: business protocol managed

The contract should be based on model contracts that correspond tostandardized business-to-business protocols, such as Open Buying on theInternet (OBI) and Rossetta.Net, a protocol for IT supply chain management.If a partner chooses not to deploy the infrastructure needed to supportexecutable contracts, that organization must hand-code all the protocolinteractions and assure that they meet the contract.

Figure 31 shows the internet managed runtime topology which is based onemerging standards for Internet-based business-to-business interactionnamed TPA described in section “Trading Partner Agreements” on page 185.A business protocol framework (BPF) manager (see 6.2.2, “The IBMBusiness-to-business Protocol Framework” on page 204) provides anexecution environment for externally exposed services and a means forintegration of the services with back-end business processes.

App 2App 3

Service

N:1async

mutually agreedmsgs

App 1


N:Msync

asyncService

Executablecontract

1:Nsync comp/decomp

rules

1:Nsync/async


Figure 31. Runtime topology: Internet managed

The Web application server, or transactional Web server, is a functionalextension of the well known informational Web server. In this topology, it runsinside a demilitarized zone where it acts as a security and routing gateway tothe enterprise network, instead of its more traditional role as a manager ofhypermedia documents and related applications.

A BPF manager generally runs under a Web application server, but runsinside the domain firewall. It manages the interactions between the tradingpartners based on an executable contract. An example of such a contract isthe Trading Partner Agreement described in section 6.2.1, “Trading PartnerAgreements” on page 185.

The actions defined in the TPA are the service interfaces that a partner isrequired to implement. Service implementations are started by an executableversion of the TPA and run in the Web application server. Serviceimplementations may use message brokering services to interact withenterprise business processes. Such brokering can be provided by the BPFmanager or by a separate message brokering server.

The internet managed runtime topology can be adapted to accommodateother types of partners. For example, in the VAN-Document runtime topology,the BPF manager could replace an EDI translation package translator if apartner is running an EDI system that employs a VAN to interact with outsideorganizations.

In this way, the executable contract and services model of the businessprotocol managed application topology can be leveraged to interact with

INTERNET



and data

internal network Demilitarized Zone(DMZ)

Dom

ain

Fire

wal

l



and data

internal networkDemilitarized Zone (DMZ)

Pro

toco

lFire

wal

l


Domain nameserver

Company BCompany A

Webapplication

server

Pro

toco

lFire

wal

l

BPFmanager

Dom

ain

Fire

wal

l

Extranet


EDI-based partners. Another example, the runtime topology, is adapted toaccommodate a message-queuing client that expects to communicate with itspartners via a VPN. Once again, the executable contract and services modelof the application topology is leveraged to interact with a different type ofpartner, in this case, one using message-oriented middleware with VPNcommunications.

4.3.1.5 Jointly managed applicationsLike business protocol managed topology, this topology maximizes flexibilitywhile providing assurance that contractual agreements are being met. Thisjointly managed topology allows both parties to assure the contract and itsspecified business protocol are being properly followed. Also like businessprotocol managed topology, it leverages the investment made in applicationintegration to extend beyond the enterprise. While it requires infrastructure onboth sides of the interaction to support executable contracts, it provides acomprehensive solution with a lesser investment in application development.

Figure 32 depicts the application topology in which the business protocolmanaged topology is extended to include business-to-business protocolmediation by both partners. The executable contract executes on both sides,guiding both partners adherence to the protocol agreed to by the tradingpartners.


Figure 32. Application topology: jointly managed

The contract should be based on model contracts that correspond tostandardized business-to-business protocols, such as Open Buying on theInternet (OBI) and Rossetta.Net, a protocol for IT supply chain management.

The Internet jointly managed runtime topology shown in Figure 33, is basedon emerging standards for Internet-based business-to-business interactionnamed TPA. Both partners employ a BPF manager to provide an executionenvironment for externally exposed services and a means for integration ofthe services with back-end business processes.

App 2

Service

App 1


N:M

asyncmutually agreed

msgs

Service

Executablecontract

1:NsyncService

Service

Executablecontract

N:1sync

sync/async

App 4

App 3

comp/decomprules

comp/decomprules

sync/asyncsync/async

sync/async


Figure 33. Runtime topology: Internet jointly managed

4.3.2 Physical patterns for B2C and B2B runtime topologiesPhysical patterns providing product mappings to populate the solutiondefined by the logical patterns. Table 15 contains the IBM product mappingfor the various nodes used in the runtime topologies described in sections4.2, “e-business patterns for B2C applications” on page 110 and 4.3,“e-business patterns for B2B applications” on page 117. The product nameswritten in boldface include XML technology.

INTERNET



and data

internal networkDemilitarized Zone (DMZ)

Pro

toco

lFire

wal

l

Company B

Webapplication

server

BPFmanager

Dom

ain

Fire

wal

l

Extranet



and data

internal network Demilitarized Zone (DMZ)

Company A

Webapplication

server

BPFmanager

Pro

toco

lFire

wal

l

Dom

ain

Fire

wal

l


Domain nameserver


Table 15. Product mappings for AIX and Windows NT

Nodes Products

Application server WebSphere Application ServerAdvanced Edition including:- XML Enabler- LotusXSL- XSL- WebSphere Transcoding PublisherJDKDB2 UDB/XML Extender

BPF manager WebSphere B2B integrator

Database DB2 UDB/XML Extender

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 FirewalleNetworkFirewall 3.2

User directDOMlotusXSL

VAN mailbox non applicable

Value added network IBM Global Network EDI Service

VPN end point non applicable

Web application server IBM HTTP ServerWebSphere Application ServerAdvanced Edition including :- XML Enabler- LotusXSL- XSL- WebSphere Transcoding PublisherJDK(JAXP)DB2 UDB/ XML ExtenderDB2 Client Application Enabler


As you can see, XML technology plays a large part in the implementation ofboth B2C and B2B solutions.

4.4 Implementation considerations for XML

Even though the XML specification was derived with both simplicity andextensive capability in mind, it can still be confusing. Additionally, with orwithout 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 buryyou in detail.

However, the design and prototyping of XML message schemes can go along way in building effective enterprise application integration solutions. Ifyour roots are also in design and modeling, you are familiar with powerfultools such as Rational Rose, PowerDesigner, and ERwin — and are probablycomfortable with their functionality and the benefits they provide. You candraw a picture, abstract, or prototype, and you can refine and generatesolutions.

The current XML specification is easy to wade through, and there arenumerous publications, books, and white papers on the topic. However, thepractical application of XML is like any other technology: You need to developa 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-basedstructures and documents. For the most part, XML is coded as simple,human-readable text. Using a text editor to develop XML DTDs anddocuments, then parsing and validating the resulting script, is a tedious taskthat can result in numerous iterations. But something as easy to use and aspowerful as an object or data modeling tool can help you find the “perfect”XML design software.

Web server redirector IBM HTTP ServerWebSphere Application ServerAdvanced EditionJDK(JAXP, XML parsers)

Nodes Products


However, no singular XML design solution can be found. Of course, there aresome great products in the XML server and the Java/XML arenas, and manyinclude companion XML design and authoring tools. But many developersneed 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 toolsand utilities” on page 63). Many of these are new and do not really leveragethe concept of “integrated development environment.”

This section intends to give you some considerations about the usage of XMLand also some ideas to take advantages from this technology.

We also recommend reading the IBM Redbook The XML Files: Using XMLand XSL with IBM WebSphere 3.0, SG24-5479-00. This book shows severaldifferent ways of how and where XML can be used in a B2B and B2Cenvironment.

4.4.1 Applications that benefit from using XMLAny applications could probably use XML, at least in a Web environment, butthere are certain applications that really benefit from it:

• Any Web application where you need to format database information intoa table, form, combo box, or similar structure, especially with integratedfiltering and sorting.

• Any Web site where you may have a fixed format but different contentdepending upon password permissions, localizations, or browser capacity.

• Any Web application where you need to transmit large quantities ofstructured information between the browser and the server.

• Any time that you need to create navigation into a hierarchical structurethat is not necessarily system dependent (for example, a table of contentsof information for files that may be located in different folders thanexpected (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 betweenclient and server, and do not want to introduce highly complexcomponents to do it.

Therefore, you should use XML in places where the data load is not huge, butmoves beyond a few bytes, as a transport protocol. You should use it inplaces 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 asuperb data transport language, and a better data transformation language.


One of the reasons that XML has taken off so extensively in the databaseworld is that it gives you a system-agnostic way of exchanging data. If youcan get your data into an XML form, then you can send it across the Internetto your customers and they can use XML to retrieve that information into theirown database system, regardless of which system is being used. The key tothis capability comes from the transformation language XSL (ExtensibleStylesheet Language), which can convert XML from one form (or schema) toanother. That way, you can build a way for your customers to query yourdatabase without compromising the integrity or security of your data.

4.4.2 Typical design for applications using XMLIf you make the decision to use XML technologies for your Web application,you’ve 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 aspurchase 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 somequeries to a database to get data required to serve client request. The XSLprocessor generates HTML streams based on the information collected bythe servlet (XML documents, query results) which are sent back to the Webapplication by the servlet. This is only a starting point; certainly the solutionwill be more complicated, but it is better to have something than nothing.Figure 34 summarizes the general design and sequence of the tasks to beimplemented for a Web application that uses XML and is notbrowser-dependent.


Figure 34. Typical design for a Web application with XML

4.4.3 A sample of an architecture for XML applicationsObject-orientation is one of the best known way to describe the structure andbehavior of complex software systems. You probably know that the structureof a particular XML application is governed by a Document Type Definition,an external file that specifies the tags and their relationship to each other. Forinstance, a DTD specifying HTML would say that a list item tag can only occurwithin a pair of tags specifying the list as ordered or unordered.

Crafting a DTD is similar to mapping an object-oriented design into arelational database schema. While it's not hard to write a schema for a simpleobject, 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 proposalsfor extensions or replacements of the DTD specification, such as the SOXproposal (www.w3.org./TR/NOTE-SOX). SOX allows you to express an XML dataset using established object-oriented terminology and, further, allows you toplace 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 stillnot ready to unleash XML. Most XML applications are built to leverage one of

XSLstylesheets

Webapplication

server

XML Parser

Client

databaselegacy

Java Servlet

XSL/XSLTprocessor

XML DOMXML DOM

HTML

XML DOM

HTML

HTML

1

2

3 4

567

8

9

XML DTDs

XMLDocuments


the panoply of XML-based standards for… well, just about everything havingto do with data manipulation, transformation, and presentation.

Extensible Stylesheet Language, or XSL, is most interesting. XSL addressesthe fundamental problems of the servlet programmer-how to design a sitethat is simultaneously dynamic, maintainable, attractive, and inclusive to allbrowsers. Simultaneously, because XSL addresses the issue of presentationof data in a browser, just as HTML does, it makes a good introduction to XMLapplications.

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 themarket. Coming to your rescue are the Open Source programmers of theJava Apache Project, in particular the server-side XSL transformation enginecalled Cocoon (see 3.2.1.1, “Cocoon — XML-based Web publishing” on page66).

Figure 35 shows how simple is to use Cocoon; for example, placing theCocoon, parser, and processor .jar files in the classpath, making the Cocoonservlet 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 awell-formed HTML document, which is sent to the client.


Figure 35. Architecture of XML application with Cocoon

The real excitement, though, is when your XML file contains multiple XSLstyle 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 theCocoon initialization file to choose between different XSL stylesheets. Thissolves what we are tempted to call the problem of Web design — support formultiple, 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 createone that works in both X and Y. The promise that the domain content could bekept in a database, and that presentation logic could be kept in individualizedtransformation files tailored to the browser is close to the ideal dynamic Website architecture.

XML and XSL do not address the issue of domain behavior. You do not wantto place such behavior in the XSL transform pages, because then you've

Webapplication

server

CocoonservletXSL/XSLT

ClientmyDoc.xml

text/xml -> servlet/org.apache.cocoon.Cocoon

myDoc.html

myDoc.html

database

myDoc.xml

OO designapproach

Java servletsXML Parser SAX

XSL stylesheetsmyDoc.xsl

XML DTDsmyDoc.dtd

XML DocumentsmyDoc.xml


fallen right back into the trap of combining presentation and domain aspects.Rather, domain behavior is the role of server-side Java components. How aremethod calls triggered? That's the role of SAX, the Simple API for XML, not tobe confused with SOX. Ideally, the XML dataset would be created by somekind of dynamic database query. The resulting dataset would be transformedby your server-side Java components, and the resulting dataset would betransformed for presentation by the XSL processor.

4.4.4 Composing Java object with XMLYou are probably familiar with runtime object composition — adding objectinstances to each other to form graphs of related objects. For example,writing a GUI without using builder tools. You construct a frame object, amenu bar object, several menu objects, some menu items, some edit fields,some buttons, and so forth. Then you add your objects to each other — menuitems to menus, menus to menu bar, menu bar to the frame, and buttons andedit fields to the content pane of the frame.

Every design with classes that allows nested composition must answer thesame question: Where is this composition defined? Very often it is in theprogram. You simply hard-code calls to constructors and add/set methods tobuild the desired graph. In other cases, the composition comes from somesort of a configuration file or registry. In that case, build a program that makessense of what's inside the file or registry and builds the graph.

This approach to composing Java objects using XML and Java ReflectionAPIs builds a program to interpret an XML document as a series of calls toconstructors and get/add methods of the objects being constructed. You feedthis interpreter an XML definition, and it composes your objects for you.When you need to rearrange your objects, change the XML definition andrerun the interpreter. No recompiling is required, not even when you add ormodify the classes of which you compose your objects; all you need to do isreflect your change in the XML definition.

This technique may often come in handy. A server can send XML definitionsof GUI frames to an extra-thin client, which interprets them to build screenobjects. When the server-side definitions change, end users see them withouthaving to download any new client code.

4.4.5 XML filtering with Java servletsWeb forms are ideal for presenting the question and answer sessionsrequired in a testing scenario. Thanks to ubiquitous Web browsers, users cantake the test from anywhere, but the automation presented here can also


grade the test and provide feedback to readers after they've answered thequestions. In principle this is all very easy to do, especially if you pick theright technologies — XML and servlets. The key strength in XML is that it wasdesigned to represent arbitrary, hierarchical data, lending structure to anotherwise potentially undistinguished piece of information. We're going to useXML to represent questions in an online test.

By using an XML parser to build a Document Object Model and using thatmodel to construct dynamically generated HTML, we can provide access to avariety of information without having to create more elaborate representationson separate Web pages.

4.4.6 XML/XSL as inputs for a Web application generatorXML/XSL can be used as inputs for a Web application generator. You wouldtake the XML pages and process each one using an XSL stylesheet, savingthe resulting HTML back to your Web server. For this, you need to know thenames of the XML pages, which you define by creating an XML file containingthe list of page names. You also need to know the stylesheets to use, so youcould use an XML processing instruction (PI) to indicate the stylesheet name.You would process PI to extract the name. Finally, you could use the samefile name as the XML file, but with a .htm extension.

Using XML and XSL to separate the page layout from the data becomes evenmore 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 oftext/xml. You can do this by configuring your server or by making the pagereturn 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 PerformanceXML does nothing to speed up the data transfer. It instead adds an elementof performance loss. Consider that the information could have been sent in asingle file as HTML with all the formatting contained in that file. The two tripsto the server would have been reduced to one, and the client-side processingwould have been eliminated. Processing an XML file results in significantadditional server load, and contributes to delays in file downloading at a timewhen research indicates fast downloads are a usability priority.


4.4.8 SecurityOne of the problems with XML is that the markup language does not providefor both secure and open transfer in the standard. Once the information is inXML format, anyone can use a parser to dump the information into adatabase. But if the same information were to be presented in HTML, it wouldbe more difficult to move the information to a database. This is because theHTML formatting does not need to be exact in order for the browser torepresent the information. While dealing with business partners, it could bemore convenient to present information in XML for data transfer. Even thoughthis doesn’t mean security, the same information could be presented in HTMLto 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 ofits ability to define and protect individual elements on a page. The XMLSecurity Suite from IBM puts tools into the hands of developers for encryptingspecific 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 aWeb-based transaction, the buyer's credit-card number is encrypted on anXML form, while the rest is unchanged.

The IBM suite of XML security tools includes XML Digital Signature, whichcan verify that a document was sent by a given party, and a hashing algorithmthat 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 fordeveloping 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 yourapplication matches.

3. Reuse existing solutions or tools for the runtime topology nodes (productmapping).

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 helpyou to implement your Web application with XML.


Chapter 5. B2C applications using XML

Business-to-customer (B2C) applications are, by far, the most common typesof e-businesses. These applications serve customers’ needs as theyexchange information, goods, and services over the Internet. In this chapterwe 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-consumerapplications. However, these categories do not cover all types of e-businesssystems. In Chapter 1, “XML and e-business applications” on page 3, wegave a general definition of B2C e-business applications. In the sectionsbelow, we revise this definition and give more precise definitions ofB2C-related terms.

We introduce the B2C market, its applications, and a general model. We alsogive a detailed description of the most common B2C application: theenterprise Web portal.

5.1.1 The field of business-customer interactionThe user-to-business area covers all activities between users (internal orexternal); and companies, including marketing, providing product information,sales, product support, customer help desk, training, and others. Some ofthese 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 sellingand 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 theircustomers, for example, Web sites with product and company information,product support via e-mail, and online purchasing via the World Wide Web.


The World Wide Web, as a unified communication and user interface method,provides key technologies for B2C applications. Companies establish Websites (called portals), design client- and server-side Web applications, andconnect these Web systems to their internal information infrastructure toimplement B2C services.

However, immature Web technologies and proprietary company informationmanagement and data exchange solutions are causing several problems intoday’s B2C solutions. The main technical problems are the following:

• It is difficult to access company data, applications, and people, due todifferences in application interfaces and management software used atdifferent companies, or even within the same company.

• Company applications use different data representations and accessmethods, 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 dueto the poor data representational formats, proprietary applicationinterfaces, and low automation level of these tasks.

• The provided services are limited — they do not utilize the full possibilitiesof today’s company information systems, because of the previouslymentioned application interface and data representation problems.

There are already several initiatives to solve these problems. Applicationproviders started to develop new interfaces and modules for their applicationsto enhance the integration with Web and other internet technologies. XMLcan also help in the solution. On one hand, it is a new Web document formatthat enhances document representation, access and presentation. On theother hand, it promises application-independent, self-describing dataexchange 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 componentsThe general model of business-to-customer applications can be divided intothree main layers:

• Client applications provide local functionality for customers. Theseapplications establish communication links to the company, propagateuser requests to the company, and present the received information to thecustomer. They can also provide client-side encryption and authentication.A typical customer client software is a Web browser.


• Front end servers handle customers’ connections and sessions. Theseservers recognize customers, manage their resources, handle theirrequests, and present information or manage the required transactions.They also include server-side encryption and authentication. A typicalfront end is a Web server with several additional modules enhancedfunctionality.

• 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, businessrules and others. They also process customer transactions receivedthrough the front end layer (for example, buying a product over theInternet). Typical back end servers are workflow management, productdata management, enterprise resource planning, and other enterpriseinformation systems.

Figure 36 shows these layers and typical components of clients, front endand back end servers.

Figure 36. The main areas of business-to-customer systems

Client side

Back end

Front end

companydatabase

back endapplicationsback end

applications

Web server

Webbrowser

back endapplicationsother client

applications

back endapplications

otherfront end

applications

Chapter 5. B2C applications using XML 141

These layers are connected to each-other using application interfaces andcommunications protocols.

• The interface between clients and front-end servers is based on Internettechnology, most commonly on the World Wide Web. Standard-basedprotocols and Web documents make it possible to use general clients fordifferent 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 severalways. They can use standard interfaces and protocols, build a distributedcomponent system, or use proprietary, company-based solutions. Typicalsolutions are based on database connectivity (ODBC), component brokerarchitecture (ORB), or general intranet protocols.

Figure 37 shows the main interfaces between B2C areas and typicalstandards used in the implementation of these interfaces.

Figure 37. Interfaces between the main areas of B2C systems

Client side

Back end

Front end

companydatabase


applications

Web server

Webbrowser

back endapplicationsother client

applications

back endapplications

otherfront end

applications

ORB Other APIHTTP

ODBC/JDBC ORB Other API


B2C applications use two methods to start transactions or disseminateinformation to users (clients).

• The client pulls the information from the server. In this way, the clientrequests a document (or starts a transaction) and the server handles thisrequest.

• The server pushes the information to the client. In this case, the serverperiodically (or occasionally) broadcasts documents to customers (forexample, a newsletter sent once a month to the company’s clients).

The typical method is the client pull, where the transaction is initiated by theclient. The client sends a request to the front end server, which processes thequery, obtains the required information, or performs the required action usingthe back end servers, generates the results, and sends them back to theclient.

From our point of view, client-side applications and back end servers aremainly out of scope. Client applications should be standardized (probablyde facto) software applications, that have uniform interfaces to the front endservers. Back end servers, mainly independent from the B2C area, are drivenby the company’s internal requirements and needs. However, applicationproviders may want to introduce new modules to facilitate e-businessconnections between the applications. Communication interfaces are alsobeyond the reach of B2C applications: they are based on standardizedInternet and Intranet technologies.

In the following chapters we will examine closely the middle layer, the frontend servers, namely the Web portal technology, that connects customers tocompany business servers. But first, we start with identifying the areas whereXML can help in designing and implementing B2C applications.

5.1.3 XML powers the B2C interactionXML plays key roles in building business-to-customer applications: it is ahighly flexible data format with strong data description capabilities, itenhances delivery and representation, and it can be used as a standarddocument 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, paperor 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-customerapplications

As a document delivery technology, XML has these advantages:

• It integrates to client application without need for manual editing orpresentation transformation.

• It allows rich presentation formats that can be individually tailored tocustomer’s needs.

• Using XML, data can be processed at the client side controlled by thecustomer for maximum flexibility.

The following sections will introduce enterprise portals, today’s products toconnect costumers to companies over the Internet. We will identify the maincomponents and the roles XML plays (or can play) in these systems.

5.2 Enterprise portals

Enterprise portals (EPs) are Web-based applications that enable companiesto connect internal and external users to their information systems, andprovide a single gateway to personalized information needed to makebusiness decisions. They play a key role in business-to-customer integration.Enterprise portals connect people (both customers and employee), data andapplications together (see Figure 38).


Figure 38. Enterprise portals connect data, applications and people together

While EP applications share a common infrastructure and features, they canbe divided into several categories, depending on the targeted users and theprimary role of the portal. Based on the targeted users, we can divide portalsinto two categories: internal and external portals.

• Internal portals are typical business-to-employee (B2E) e-businessapplications. They link employees to internal information resources ofdifferent kinds, like product information for sales or support, customerdata, calendar of events, discussion forums, and others.

• External portals allow customers to access company data and applicationsaccording to their needs and company regulations, and they help inmanaging 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-commercetrading systems.

• Information portals organize information by subject or theme, publishnews, events, product, service and company information, and so on. Theyrely on information and data management systems to achieve these goals.

• Knowledge portals are specialized information systems, that storecompany’s knowledge about products, services, their use, and providesolutions to typical problems. They also use additional techniques thaninformation portals, typically knowledge management tools.

databack end

applicationsapplicationspeople

access and integration


• Collaborative portals enable teams of users to establish virtualcommunities to manage their work, projects and contacts. These systemsuse special applications for project and contact management, discussionboards, and other tasks.

• e-commerce portals are trading applications that establish Web-basedproduct and service stores to allow users to browse catalogs, collectinformation, and buy goods over the Internet. They use productmanagement tools, online ordering, electronic payment and otherapplications 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 sametime. From the customer’s point of view, it is clear that the best portalintegrates everything, and has a unified presentation and access. From thedesigners perspective, however, it is worth distinguishing between thedifferent portal types.

The XML technology plays a key role in these areas as we will present it inthe following chapters. It can enhance almost all fields in portal applicationslike data exchange, representation and presentation, applicationinteroperability, and customization.

5.2.1 Data and application integrationThe key element in establishing business portals is the integration ofcompany 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 andapplications. This can be done through application interfaces for dataaccess, or using advanced data and text mining tools.

• Service integration means providing access through the portal tocompany 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 ofapplications, 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.


• Internet and Intranet integration means providing access for both internaland external users, maintaining different access options, content andservices.

• Integrating different front end portals means that the company builds asolid, 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 serviceprovider, who integrates different companies’ portals into a commonframe, and resells their services and products to customers.

Figure 39. Integrating clients, applications, and portals

Data and application integration is the primary area where XML can help inbuilding B2C applications. As a document exchange format, it canstandardize the data exchange between front and back end servers, making

client

back end

client

back end

client

Internet Intranet

back end

client

back end

portalCompany A

Company B

Company C

client

Internet portal Internet and Intranet portal

Integrated portal Service provider for portals

portal

portal portal

portal

portalportal

portalportal

Internet


more legacy data and applications accessible from e-business applications.Using XML technologies (especially style sheets and XML-basedtranscoding), client applications receive documents in more appropriateformat from enterprise portals, and they also can perform more complextasks and integrate client applications in more flexible way. As a documentdescription format, XML allows greater flexibility, richer set of tools for contentgeneration, automated maintenance and update, and more powerfulpersonalization services.

In the following section we examine closely the content managementsubsystem of an enterprise portal, which is responsible for collecting,managing, maintaining and enterprise data for portal users.

5.2.2 Content managementContent management takes place between a document’s creation and it usein the portal by organizing unstructured data into a structured informationcollection that can be shared, searched, manipulated, analyzed andmaintained. The content of a portal can be created automatically usingcompany information sources, or after manual data collection and documentauthoring. It is undoubted that the automation of these systems greatly helpscompanies by reducing costs, shortening publication times, and increasingportal information completeness. Content management can greatly help inkeeping the enterprise portal up-to-date, enabling personalization accordingto user’s need, and reducing human resource and time costs.

Content management systems perform several tasks in portals. Figure 40shows the general architecture of a content management system.

• Data retrieval from several sources is the first step in contentmanagement. On one hand, this means the automatic retrieval of datafrom company back end applications, converting these information into theportal’s representational format, storing meta information about theretrieved data, and inserting the data into the structured portal content. Onthe other hand, it could also mean the manual authoring of portal content.In some cases, the content is only stored in the portal’s content databaseas a reference to the original data (for example, product availability, priceinformation, and similar data can be obtained directly from back endapplications).

• Document storage and management is responsible for maintaining theportal’s information repository. This includes handling metadatainformation about the documents (for example, author, topics, format,source, contacts, subscription information, and others). The documentmanagement system is also responsible for managing relations between


documents, creating compound documents, controlling documentpropagation, tracking versions of documents, and performing thenecessary update when source data has changed.

• Security and access services are responsible for maintaining informationabout document access rights, and controlling document access by users.This is done by identifying individual users, maintaining document accessinformation, and performing the necessary filtering on the presenteddocuments. In simple cases, this means granting or denying access tocertain documents. In more advanced systems, this can be based on thestructure of the documents, and presented documents can be filteredaccording to the user’s access rights.

• Personalization of content management services is a very importantservice in enterprise portals. It means the tailoring of the informationcontent and presentation format according to individual user needs. Thecontent management system is responsible for assembling the informationin 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 userprofile), or categories of users.

Figure 40. Content management general architecture

Today’s Web and data exchange technologies do not really help in buildingautomated content management systems. HTML, the main Web document

Portalcontent

Userdata

Contentby

reference

Contentmanager

companydatabase


applications

retrieveddata

displayeddata

portaluser


format only concentrates on the presentation, and company applications lacka common, self-descriptive data representation. XML can play a significantrole in content management in several fields.

• XML is a unified data format for representing metadata and structureddocuments. It can be used in the portal to define the content descriptionlanguage, that helps in structuring the portal content. Based on thistechnology more advanced search and filtering capabilities can be usedusing metadata and structure information. It also allows the automaticvalidation 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 thesefragments to create new documents.

• The XSL and XSLT standards can be used to search and filter informationin XML documents. However, as query and search tools, they have ratherlimited capabilities. XML Query Tools help in building advanced query andsearch facilities. As the SQL language in databases system, a similarlanguage in XML will enhance and standardize the document querydescription and processing. Currently, however, there are no standards forbuilding such tools. See 1.2.11, “XML query languages” on page 25 formore details about current initiatives and proposals.

• XML is a unified data exchange format, since more and more vendorsimplement XML interfaces in their applications (see 3.4, “XML extensionsto IBM products” on page 89 for details about XML support in IBMproducts). Data retrieval from different kinds of applications can be donein a uniform way using XML. This allows the mapping between many datadescriptions and a single document type convention used by theinformation portal. It also helps in transferring complex, self-describingdata structures from back end to front end applications.

• XML can also be used in security and personalization services as adocument format for describing resources and users. See the sections5.2.3, “Controlled access to structured information” on page 151, and5.2.4, “Customer relations, recognition, and personalization” on page 152for more details.

• XML is the future Web document format. As more and more browservendors implement XML support in their products, XML becomes the newstandard document format in Web client applications as well. Along withother technologies (like XSL for formatting and filtering, or XPointer, XPathand XLink for addressing and linking XML documents) it allows morecomplex client tasks to be performed than today’s browsers.

Figure 41 shows how XML fits into the content management architecture.


Figure 41. Content management using XML

5.2.3 Controlled access to structured informationAuthorization and security are main issues in networked environments,especially on the Internet. Most of these topics are beyond the scope of thisbook. However, it is worth to discuss new issues the XML technologyintroduces in securing XML-based Web portals.

In a structured document it is possible to assign access rights to users basedon the structure of the document. For example, a document describing acustomer may have different access rights to company sales personnel, tothe customer itself, and to other customers; different parts of the profile maybe accessible for different types of users. This kind of policy can be based onthe document type definition. However, the DTD is not always available, sinceit is not required for XML documents. XML documents are also inter-linked,they could contain information from other documents. This is also true forDTDs. These links may or may not be visible for users (based on accessrights), that also complicates the access right resolution.

Moreover, the population of XML documents changes dynamically, and thedocument types cannot be known a priori, during the time of establishingaccess policies. Due to this nature of XML document bases, it is not possibleto create fixed access rights. Instead, it requires a dynamic, credential-baseddocument access management.

Portalcontent

Userdata

Contentby

reference

Contentmanager

companydatabase


applications

retrieveddata

displayeddata

portaluser

XMLXML

XMLXML

XMLXML


So far, there is no support or common solution for this kind of access controlin XML-based document management systems. Current applications usedocument-based access restrictions, which are also in used in the WorldWide Web environment.

5.2.4 Customer relations, recognition, and personalizationPersonalization at enterprise portals allows highly customizable access to theportal by providing tools and methods to compose personalized collections,user interface, and preferences. This feature helps customers to tunecompany interfaces to their needs, and to obtain information and services inthe way they like. It also helps companies to understand customers’ needsand tailor the information content and services of their portals. Usingpersonalization techniques, a portal site becomes more attractive and moreproductive.

These are requirements for portal systems when they establish personalizedservices:

• They maintain user profiles that contain all required user information toprovide personalized services and maintain customer relations.

• Security services are needed to allow customer identification, accesscontrol, and ensure customer privacy.

• Dynamic content creation is required to compose documents dynamically,according to the user’s preferences. This is based on some kind ofmatching/search technology.

• Personalization tools are needed to allow the user to set his/herpreferences, and to provide feedback to the company about the portalservices.

Figure 42 shows the general architecture for personalization and maintaininguser data in portals.


Figure 42. Personalization in enterprise portals

The customization and the quality of dynamic content generation is they keyelement in personalization. There are several approaches to buildprofile-based content generation. The content presented to the user can becreated in different ways from the master content of the portal:

• Simple filtering displays the content by filtering the master contentaccording to the user’s profile and the actual information shown. Forexample, if a user is a customer, and currently visits a customer supportWeb site, the portal may want to show links to customer-related supportsites within the company.

• Rule-based content generation generates content according to rules andinformation from the user’s profile. Rule-based content generators makesimple decisions based on available information. For example, if a

User andprofile

database

My fa voritelinks

My Personalized PageSuggested items of interest:

New financing options announced

Appl icat ions I am autho rized to use :Enter ordersCredit status

Co mpany poli cy manuals I have access to :VacationHealth pl an

Requesthandling

client side front end

Businesslogic

input processinguser identification

content retrievalpersonalizationdocument assembly

Outputgeneration

transcodingoutput generation

back end

Businessapplications

Services and content


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 toenhance the content for a user. It takes into consideration similaritiesbetween users and other users’ actions and preferences to generate amore appropriate content for a certain situation. For example, customersmay receive recommendations based on product evaluation of users withsimilar interest profile.

• Statistical methods try to make inferences based on previous history data.They can use different methods, for example, neural networks orprobability vectors to model the user’s preferences. For example, a portalsite 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 theperson would buy next time.

• Advanced user modeling techniques build complex models of users tosimulate and predict their behavior. They may also model the informationand services available in the portal application. This model is calleddomain model. Based on domain and user models they can simulate theuser’s behavior, and optimize the behavior (services, features, content) ofthe portal.

User profiles that store information about the user can be created in differentways:

• Explicit profiling asks the users directly about their interests. This can bedone, for example, by completing a short questionnaire or by some otherexplicit action. This method has the advantage of letting the customer tellthe site directly what they want to see. However, site visitors are oftencautious when supplying information and may decline to complete longquestionnaires. They may not want to spend several minutes on filling outforms and answering questions. This step may be broken into severalparts. The first part, for example, during registration of the users, onlyidentifies the key priorities. Later, for example, when the user intends tobuy a product, the profile management may want to collect moreinformation about the user by asking questions about product features.

• The implicit profiling method collect information about the user withoutasking direct questions. The system instead monitors the actions of a sitevisitor (pages viewed, items purchased, and so on) and infers from theseactions the interests of the user. This has the advantage of not requiringthe site visitor to complete a questionnaire. Interests inferred from clickstream patterns may not always be as accurate as those gathered fromexplicit site visitor input.


• Many companies have a rich source of profile information in their legacysystems in the form of credit applications, previous purchases and soforth. For existing customers and known visitors, use of legacy data oftenprovides the richest source of profile information.

While user modeling plays an important role in portal applications, in mostcases 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 incertain business-to-customer situations, for example, in productrecommendations and knowledge-based product support.

XML technologies play several roles in customization and personalization ofenterprise portals. As a structured content description format, it allows thecustomization (filtering) of document content according to the client’s needsand 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 withother document parts to dynamically create new documents. The structuredformat and the additional metadata information can greatly enhance searchcapabilities of enterprise portals.

XML-related representation standards, like XSL and XSLT, enrich thepresentational capabilities of current Web applications. On the server side, itis possible to generate different output document formats for different clientneeds. This makes possible different media types at the same time from thesame data source. These media types can be paper, CD-ROM, or online Webpresentation. XML styling can also help in the automatic transcoding ofdocuments into the client’s preferred format. Based on the Web browseroperating environment, display capabilities, and connection speed, the portalcan be displayed with high resolution images, in text-only format, or in a morecompact way for wireless applications.

Finally, XML can also be used as a standard for describing customer datathat can be easily interchanged between applications and companies. Thismethod can be combined with database technologies for greater flexibilityand access. Two examples for this field are the DSML and CPEX standardproposals.

The Directory Services Markup Language (DSML, http://www.dsml.org) is anindustry proposal for representing directory services in XML format. Directoryservices provide an optimal way of naming, describing, finding and retrievinginformation 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


XML-based applications with directory information in their native environmentand data format. It specifies a standard schema for representing this kind ofmeta data in XML documents. It also allows easy and standardized datatransfers between companies.

Another example is the Customer Profile Exchange (CPEX,http://www.oasis-open.org/cover/cpex.html) initiative, which is an industryorganization dedicated to “developing an open standard to facilitate theexchange of privacy-enabled customer information across enterpriseapplications. The CPEX standard integrates online and offline customer datain an XML-based data model for use within various enterprise applicationsboth on and off the Web”.

5.2.5 Business intelligence and enterprise portalsSo far we considered enterprise portals as information provides that collectdata from enterprise applications, store this data as documents in the contentdatabase, and present these documents to users according to their profilesand access rights. However, enterprise portals can also provide interface tobusiness intelligence to report on-line business information.

Querying business information is already a growing market in the enterpriseportal 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 usersas simple reports (for example, monthly sales statistics), for moreprofessional business users as sophisticated ad hoc queries (like what arethe top five product categories sold to insurance companies), for businessanalyst as OLAP viewers, and for power users as data mining services.

Query reporting products used to present aggregated data from companysources upon request or subscription. Metadata, or information about thedata, provides business users information about data and information objectsthey can access. There are two types of metadata: technical and business.Technical metadata provides the technical description that includes sourceformat, creation and modification date, availability, and so on. Thisinformation can be used to extract, filter, transform, maintain, and updatesource data. Business metadata is used by business analysts and end usersand 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 metadatadescription and exchange format, and to integrate and structure different datainto content documents. The XMI (XML Metadata Interchange) specification


by OMG specifies an open information interchange model that is intended togive developers an industry standard for combining the benefits of theWeb-based XML standard for defining, validating, and sharing documentformats on the Web with the benefits of the object-oriented Unified ModelingLanguage (UML) that provides application developers a common languagefor specifying, visualizing, constructing, and documenting distributed objectsand business models.

5.2.6 Connection to e-commercee-commerce (seller-to-buyer) is the exchange of goods and services betweenvendors and consumers over the Internet. This market is also referred azelectronic retail, or e-retail. These application are usually based on Webtechnology, they use Web servers and browsers to connect vendors andconsumers 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 theclient’s side with possible applications for electronic payment (for example,an e-wallet), a front end Web server, and back end business applications atthe merchant’s side. The back end applications include a database server forstoring product information (specifications, price, availability, and so on), andan application that manages trading transactions. In some cases, a third partyis involved in the transactions to perform on-line payment transactions.

Usually, the merchant’s Web server performs several queries to the databaseand builds HTML pages dynamically to present the actual offerings to thecustomer. Then the customer selects products and places them into a virtualshopping cart, which is a part of the back end business logic application.Finally, the customer proceeds to the checkout and orders the products thatare in the cart. After the order, the customer can select a payment method, orpay for the goods online.

Behind the scenes there are server side applications running and performingdatabase operations. These applications can be purchased as completepackages from e-retail application vendors, or they can be created using coretechnology elements and software development kits from e-retail softwarevendors.

Security has always been a central issue in these systems. Sending data (forexample, credit card information) over the Internet concerns manycustomers. On the other hand, the security of merchant servers (for example,that store customer data) also becoming an important issue in these


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. Providingcustomizable services to buyers became a standardized part in most of theseapplications, software vendors already include these features in theirapplications. Merchants also try to collect more and more information abouttheir users, and build more sophisticated user models, to enhance theirservices.

Tomorrow’s Web will use the XML to encode information about products andservices with meaningful structure and semantics that can be used to buildmore precise search and matching algorithms. Vendors can use the XMLformat to describe and publish information about their products and servicesin a way that other companies’, merchants’ and customers’ applicationsunderstand. This eliminates the need for custom product interfaces betweenvendors, merchants and customers. It also makes electronic commerceapplications ready to automate, to use by customer’s software agents thatcollect and compare information automatically. However, merchants mightinitially dread that XML-encoded information makes too easy for customers tocompare specifications and prices with competitors.

XML, as a meta language makes it possible to create specialized markuplanguages (vocabularies) for selling and buying goods and services. Themain areas for XML in e-commerce are metadata descriptions of productsand services, and information exchange between companies. XML RDF(Resource Description Framework) and XMI (XML Metadata Interchange) aretypical base standards that enable higher level specifications to bedeveloped. See 1.2.7, “Metadata (RDF and PICS)” on page 21 for moredetails about these base standards.

To maintain the interoperability between various vendor systems, there is aneed for standardized XML vocabularies. There are several initiatives tosolve this problem. IBM is working with the industry to develop standards fore-commerce. There is a tremendous amount of activity within IBM and acrossthe industry in using XML for commerce standards. There are numerous usesfor XML, but the following proposed standards relate to commerce and reflectIBM's participation. Although these initiatives primary concentrate on thebusiness-to-business part of e-commerce, some parts also refer to thebusiness-to-customer relation.

• Product Information Exchange (PIX) is a set of protocols that supportcatalog interoperability on the Internet through defined guidelines for


content, communication, format and presentation of product data. PIX isunder development by CommerceNet members (http://www.commerce.net).

• Information and Content Exchange (ICE, http://www.w3.org/TR/NOTE-ice) isa proposal of content providers like CNET, News Corp., Vignette andothers to create and manage networked relationships, such as syndicatepublishing networks, Web superstores, and online reseller channels.

• The Open Trading Protocol (OTP, http://www.otp.org) is a specification ofa 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 andservices, delivery, receipts for purchases, multiple methods of payment;and support for problem resolution. OTP is focused on interchangebetween consumers, merchants and support services. OTP is beingdeveloped by the "Trade" working group of the Internet Engineering TaskForce (IETF).

• Open Buying on the Internet (OBI, http://www.openbuy.org) is an initiativelaunched by American Express and major buying and sellingorganizations. It automates the large-scale corporate procurement ofoffice and maintenance supplies.

• Open Financial Exchange (OFX, http://www.ofx.net) is proposed byCheckFree, Intuit and Microsoft. It describes the electronic exchange offinancial statements among consumers, small businesses, and financialinstitutions. It supports on-line banking, bill payment, investment, andfinancial planning activities.

• The Platform for Privacy Preferences Project (P3P) provides a frameworkfor informed online interactions. The goal of P3P is to enable users toexercise preferences over Web sites' privacy practices. P3P applicationswill allow users to be informed about Web site practices, delegatedecisions to their computer agent when they wish, and tailor relationshipswith specific sites. P3P is a project under W3C.

• XML/EDI (http://www.xmledi.com) is a specification of a group ofCommerceNet, ANSI X12, and Graphics Communication Association. Itdefines how traditional X12 EDI business data elements can berepresented using XML.

• RosettaNet (http://www.rosettanet.org) is a PC industry initiative. Itdefines how PC product catalogs and transactions should be describedamong 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


exchanged among Internet commerce transaction partners and marketparticipants. Business documents include product descriptions, purchaseorders, invoices, and shipping schedules.

• Commerce Extensible Markup Language (cXML, http://www.cxml.org)aims to standardize a single open language for communication betweenbuyers, 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 industrialmovements, IBM also develops product lines to facilitate e-commercesolutions. The main product line is the WebSphere Commerce Suite (formerlyNet.Commerce), which is a full e-commerce solution for both B2B and B2Cmarkets. See 5.3, “IBM products and tools in B2C applications” on page 165for a more detailed description.

5.2.7 New presentation devicesAs new presentation devices, such as mobile phones and personal digitalassistant (PDA), appear on the market, the “wireless Web” becomes aneveryday technology. Display and bandwidth characteristics of these devicesrequire different representation and presentation techniques that in normalWeb applications.

The most known wireless Internet access service environment is the WAE, orWireless 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 protocolspecification that works across differing wireless network technology types,for adoption by appropriate industry standards bodies. The WirelessApplication Protocol (WAP) is a result of this work. The XML technology isextensively used in the Wireless Application Environment.

The Wireless Application Environment Specification (WAE,http://www.wapforum.org) contains several documents that describe theapplication environment. The World Wide Web Consortium (W3C,http://www.w3.org) works together with the WAP Forum to provide protocolsand specifications for wireless Web applications. The CompositeCapability/Preference Profiles (CC/PP, http://www.w3.org/TR/NOTE-CCPP)based on XML and RDF is a W3C specification proposal (W3C Note) todescribe capabilities and user preferences at the client side. See 1.2.9, “XMLin wireless applications” on page 23 for more details about thesespecifications.


The W3C Mobile Access Activity describes a system based on the CC/PP forWeb applications. They propose that CC/PP could be used in Webapplications to provide standardized descriptions of the clients. When a clientdevice makes a request for a Web document, it sends an URL to its resourcedescription (along with the URL to the requested document). This URL goesstraight to the CC/PP database. This means that the profile of the device willbecome available to the Web server. On this bases the server can create theappropriate content for the device (and user).

There are several ways to create different content for different profiles. Therecould be previously created content files for different devices. There could bea mechanism for creating these pages on the fly by transcoding otherdocuments. Figure 43 shows an example transcoding architecture from anearlier 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 differentways of presentation. According to W3C activities, XHTML is being designed


as a series of modules associated with different functionality: text, tables,forms, images, and so on. If a content provider wants information to beavailable for different devices, different versions of that content can begenerated with simple version perhaps using on the basic text modules,graduating to full graphics with scripting, and so on. The document thusspecifies the expected capabilities of the browser in terms of HTML support,style sheet support and so on, in different document profiles. These profilesthen could be matched with device profiles to select the best document forthe viewer.

5.2.8 IBM portal examplesThere are several IBM initiatives to create different kinds of portals for publicuse. IBM as a company has its own business-to-customer applications toprovide information and services for customers, developers and the Internetcommunity.

IBM home pageAs part of maintaining its home page (http://www.ibm.com) IBM introducedXML in the production environment. It uses a variety of XML-relatedtechnologies, including XSL, XML Fragments, XLinks, and XPointers.

The ibm.com Web site is one of the busiest on the Web, receiving an averageof 8 to 10 million hits a day. It is the entry point to IBM’s Internet presence.Currently it manages more than 2 gigabytes of information. Obviously, withsuch a large site, content management is a constant problem. In addition tothe normal problems involved with managing an enormous Web site, ibm.comundergoes 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 thesite.

• 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 newsvocabulary 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 informationabout the content. The shop DTD is designed to standardize the descriptionof all products orderable through ibm.com. Encoding product descriptionsusing this DTD makes it easy to retrieve information about IBM products, andit makes comparing similar products easier as well. The search results DTD


was written to simplify searches across the ibm.com site. When a user asks forinformation, the results of that request are marked up using our searchresults DTD. This makes it easy for the user to find further information orrelated information, based on their original search. The product navigationDTD allows to define a class of documents to find specifications, supportinformation, 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. Thefirst prototype used the client to process XML markup. The second prototypeIBM’s XML Enabler, a Java servlet that processes XML documents and XSLstylesheets to generate HTML documents dynamically. Finally, the thirdprototype (Figure 45), which is used in production at the time writing thisbook, converts the XML documents into the various HTML pages before anyclient requests were processed. It uses XSL to format the pages into theoutput presentation format. When requests come in, it can quickly determinewhich preprocessed XML document matches the request, then return thatdocument to the user. Because XML- and XSL-enabled browsers arebeginning to appear on the market, there is also a caching mechanism toserve the original XML and XSL documents to browsers capable of renderingthem. This allows the client machine to provide additional function, such as


an XML source view, not possible with the generated HTML file. This latestapproach is scalable to the traffic volumes used by ibm.com.

Figure 45. Prototype architecture for ibm.com

Patent ServerThe IBM Intellectual Property Network (http://www.patents.ibm.com) is apremier Web site for searching, viewing, and analyzing patent documents.The IPN provides free access to a wide variety of data collections and patentinformation 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 patentnumber, a simple query will return the essential information for that patent.More complex searching interfaces provide free-form searches that caninclude all of the patent office bibliographic data fields, and the claims.


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 24Gigabytes of patent text information. All systems are running on IBM RS/6000and SP servers using the AIX operating system. The content is delivered tothe Internet via the IBM Global Network.

Developer portalThe developerWorks portal (http://www.developer.ibm.com) is a part of theIBM Partnerworld for Developers worldwide program supporting developerswho build solutions using IBM technologies.

The portal’s new data model design is based on XML. The site designerscreated DTDs for developer-related content (standards, news stories, casestudies, tool descriptions, and so on). They facilitate XSL translations topossible share the content with other developer-related Web sites, and todistinguish the presentation from the information content. The current versionuses a Domino server for storing and serving documents. The new version(Phase 2) will rely on DB2 and XML Extender technologies for betterperformance. Depending on the client’s needs, the content will server inHTML, or using XML/XSL.

My dW, as part of the portal services, provides personalization support for thesite. Phase 2 uses Lotus Domino R5 as the Web application server thatorganizes and manages user profiles, developerWorks content, andpersonalization rules. The user profile information is stored in a DB2database, and the rule manipulations and content associations are also donein DB2. A Java servlet establishes the link between Domino and DB2databases 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 buildbusiness-to-consumer applications. We give a short introduction to eachproduct and describe how XML fits into them. The last section describes howIBM tools and products fit into various areas of enterprise portals. For moreinformation about IBM e-business frameworks and products, see the sections2.2, “IBM Application Framework for e-business” on page 37, and 3.4, “XMLextensions to IBM products” on page 89.


The IBM e-business strategy covers all business-to-customer areas. IBMproduct suites integrate applications, data, and people together into acoherent system (Figure 46).

Figure 46. IBM product suites in business-to-customer integration

5.3.1 Enterprise Information PortalIBM and Lotus have begun the launch of a unified e-business portal strategyincluding initial offerings and a partnership initiative. The IBM EnterpriseInformation Portal is a solution to build and manage enterprise portalapplications (see Figure 47).

DevelopmentDevelopment

ApplicationsApplicationsInformationInformation PeoplePeople

EIP RavenWebsphere

Access and integrationAccess and integration


Figure 47. IBM Enterprise Information Portal architecture

5.3.1.1 Content ManagerThe IBM Enterprise Information Portal has connectors to IBM ContentManager 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 digitalinformation with a single product. IBM Content Manager V6.1 is a solution forstorage, management, and distribution of all types of digital content, includingtext, images, audio, and video. This new integrated offering combines thestrengths of EDMSuite ImagePlus VisualInfo and DB2 Digital Library toprovide a comprehensive approach to all aspects of digital informationprocessing.

IBM Enterprise Information Portal (EIP)

Custom Portal Applications

...BusinessIntelligenceConnectors

WorkflowIntelligentMining

FederatedSearch

InformationConnectors

RichMedia

Repository

ScannedDocuments,Compoter

Output

Intranet &Internet

Sites

ERPSystemContent

CollaborativeDocument

Library

DB2 IMSVSAMOracleSybase


Content Manager integrates functions and technologies that, combinedtogether:

• Provide a single solution to manage a full range of digital content toleverage business and other information including, but not limited to:Images, PC files, Business documents, Video and audio clips, XML andHTML structured documents, and Computer-generated output.

• Enable exploitation of multimedia content in e-business environments andacross traditional client applications Provide highly scalable capture andindexing of documents, with optimized storage management, forenterprise-wide capability

5.3.2 Lotus Raven suiteLotus Raven is a new knowledge management suite. It includes two mainparts: a portal solution, and a knowledge discovery engine. It has severalcomponents like application integration, content tracking and analysis, userprofiles, and expertise locators. These components are integrated into aportal to manage personal and community information and activity.

Figure 48. Lotus Raven knowledge portal architecture

Figure 48 shows the general architecture of the Lotus Raven suite. The portalorganizes assets by community, interest, task or job focus. The discovery

Custom Portal"Raven" Knowledge Portal

"Raven" Discovery Engine

ExpertiseLocator

ContentCatalog

FileSystem

otherWebSites

DominoDatabases

DocumentLibrary


engine locates, retrieves, and categorizes content and organizationalexpertise into a browseable and searchable catalog.

Raven's knowledge portal organizes all information for a user. Theseinformation include applications and contacts by community, interest, task orjob 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. TheseKnowledge Windows are extensible and can support any Domino ornon-Domino application. The relation between Raven and EIP can be seen inFigure 49.

Figure 49. Integrating Lotus Raven and IBM Enterprise Information Portal

The Discovery Engine crawls documents and creates a browseable catalogcontent and expertise. The catalog is a "table of contents" of all the writteninformation and internal expertise that exists within an organization.Theengine constantly refreshes the catalog by tracking user characteristics andusage activity. The result is a system that reflects much about an organizationin terms of where things are, who knows what, what is important, and whatsubjects generate the most interest and interactivity.

The Discovery Engine has two main components: the Expertise Locator andthe Content Catalog. The Expertise Locator builds and maintains profiles in a

"Raven" Knowledge Portal

IBM Enterprise Information Portal (EIP)

"Raven" Discovery Engine

Custom Portal Applications

InformationConnectors

FederatedSearch

IntelligentMining

WorkflowBus Intelligence

Connections...

FileSystem

Web SiteDomino

DatabasesDocument

Library

ERPRDBMS

Rich MediaRepository


repository that can be queried directly by users to locate experts by skill,experience, project, education, job type and many other attributes. TheContent Catalog crawls text sources to identify topics, and groups similarcontent into browseable categories, called content maps. It also derivespeople's skills from content they have authored or read, and maps them tothe categories alongside documents.

By subscribing to specific categories that interest them, users can direct theirknowledge portals to deliver to them relevant information about news,projects, people, and organizational structure. Raven uses IBM's DB2Universal Database as the underlying technology to manage the catalog andthe complex analyses processes.

Figure 50 shows a sample screenshot from a Raven portal application.

Figure 50. A sample screenshot of a Lotus Raven portal


5.3.3 IBM WebSphereThe WebSphere product family provides a comprehensive basis fordeveloping custom e-business applications. It provides a full scale of servicesfor different types of tasks like e-commerce, personalization, transcoding, andothers.

The WebSphere HTTP Application profile isolates business logic, andpresentation. It defines an architecture for integrating applications, and datainto business-to-customer applications (see Figure 51).

Figure 51. WebSphere integrates users, data, applications; offers portal services

Pageconstruction

Interactioncontrol

port

alse

rvic

esac

cess

toin

form

atio

n

EIP

DigitalLibrary

WCM

EABCommands

MQ

CICSMQSeriesSAPothers

Command beans

Servlets

JSPs

clients

acce

ssto

data

metadata handlingresource definitionsuser definitionspersonalizationrules


WebSphere Commerce Suite (Net.Commerce)IBM WebSphere Commerce Suite (formerly Net.Commerce) is a full solutionto e-commerce applications. It is among the most widely used Webapplications in this market. It supports both B2B and B2C applications.

The product contains a rule-based personalization framework. It includes aflexible rule processor that can perform simple rule evaluations as well asmore complex inference procedures.

WebSphere Commerce Studio is a large array of tools in the CommerceSuite. These tools provide all functionality for administrative, technical, andbusiness management, as well as tools for design, development, deployment,and maintenance.

TranscodingThe IBM Transcoding Technology contains a set of basic contenttransformations for modifying Web data, such as HTML pages, GIF or JPEGimages, and XML documents. It uses standards-based technologies for thedata transformation, including Java, XML, XSL, Wireless Application Protocol(WAP), and Wireless Markup Language (WML). It uses JImage, astandards-based IBM Research technology, to transcode images, photos,and graphics.The initial content transformation mechanisms can be extendedby IBM, independent software vendors (ISVs), or customers using plug-ins.

The WebSphere Transcoding Publisher contains a set of transcoder plug-insthat transform Web content:

• Modify HTML documents, such as convert images to links to retrieveimages; 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 adevice; and remove comments.

• Transcode GIF and JPEG images by reducing scale, color level, or both tomake images smaller, easier to transfer, and quicker to render onconstrained devices.

• Convert JPEG images to GIF images for devices that support only GIFimages.

• Transform XML documents by selecting and applying the right stylesheetfor the current request based on information in the relevant profiles.

• Define profiles for preferred transcoding services for an initial set ofdevices, such as the 3COM Palm Pilot III using versions of HandWEB,


handheld Windows CE devices using Pocket Internet Explorer, andWAP-enabled phones using WML viewers.

The transcoding architecture is highly customizable (see Figure 52). It is apluggable framework, that contains a set of transcoder plug-ins. Newtranscoders can be added and can interact with existing transcoders.Combining the extensible WBI intermediary backbone with the transcodingmechanisms produces a Web proxy that can be used to transform imagesand text according to user, network, and device preferences.

Figure 52. WebSphere transcoding customization

The Publisher also has a developer’s toolkit for building custom transcodingplug-ins, and administration services to control the configuration andpreference profiles.

WebSphere personalizationWebSphere provides several components to deploy personalized solutions. Ithandles user profiles, allow the definition and management of rules forpersonalization, and has a content model that stores attributes and hierarchyof documents. The WebSphere product family also offers development toolsto build personalized Web applications.

WebSphere User Profile is an Enterprise Java Bean that implements theWebSphere Resource class. It can be mapped to an existing database, toother data sources, and a new database can also be created during thedefinition of the user profile. WebSphere Rules class describe actions in

Administration

Transcoding framework

ProfilesDevelopertoolkit Text XML customImage . . .

modifying existingdeveloping new readily available transformation plug-ins

device profileapplication profileuser profilenetwork preferences

framework for plug-in interoperability

customer-providedtransformation

common transformation rules

framework configuration

registration of stylesheets

Transformation plug-ins


certain situations in Web applications. They fill out information in a page, orclassify the situation. RuleImplementator is a Java class that implements thealgorithm of a rule. This algorithm may test for several conditions, performactions according to the conditions, and can interface with other componentsor applications.

WebSphere Studio allows the development of applications withpersonalization rule support. The Rule Editor helps in developing businessrules 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 userand content attributes, hierarchy, and generates management HTML pagesand servlets.

5.3.4 IBM products and tools in portalsIn Table 16 we summarized the main IBM products and tools in each field ofenterprise portal applications described in 5.2, “Enterprise portals” on page144”.

Table 16. IBM products and tools in building enterprise portals

Area IBM Products and tools

Content management DB2 KnowledgeX,DB2 Intelligent Miner for Text, Intelligent Miner for DataVisual Warehouse, DB2 OLAP ServerDB2 Digital Library, Content ServerClever, Domino (extended search)Lotus LearningSpace

Security andaccess control

ODS, SecureWay, Domino, WebSphereWebSphere 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 andbusiness intelligence

MQ Series, BIS, DominoB2B Server, FlowmarkWebSphere 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 adetailed description of enterprise portals that are the most common B2Capplications.

We characterized what roles XML can play in building B2C applications. As asource data description format, it can help in metadata description, structureddata representation, automatic document validation, document management,and different presentation. As a document exchange format, it standardizesapplication data exchange, integrates data from different sources, andtransfers complex application data in an application-independent way. As adocument delivery technology, it enhances client presentation, integrates withother client applications, and advances data processing at the client side.

Enterprise portals, as a mainstream technology for business-to-customere-business, share a common, layered architecture, and have severalimportant features and components such as data and application integrationwith users, content management, user recognition, and personalization. Weshowed how XML can help in improving these areas.

At the end of the chapter we presented IBM portal initiatives, B2C productofferings, and tools for building enterprise portals.


Chapter 6. B2B applications using XML

The aim of this chapter is to help the reader to understand the role that XMLcan play in the business-to-business application context, as well as what IBMis doing in helping companies in this particular field. Business-to-business willbe positioned as one of the best opportunities of the emerging businessintegration IT challenge for the next years.

Inter-company business integration technologies that can support the nextbusiness models, such as Trading Partner Agreements (TPAs) and theBusiness-to-business Protocol Framework (BPF), both proposed by IBM.These technologies are the basic building blocks of IBM WebSphere B2BIntegrator, the B2B XML-based framework announced by IBM.

At the end of the chapter we present an outline solution to build TradingPartner 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 improvebusiness-to-business partnerships and transform inter-organizationalrelationships. B2B trade may be conducted between a company/organizationand its supply chain, as well as between a company/organization and othercompany/organization end-customers. Trading can be conducted directlybetween buyers and sellers and/or supported by a third party (anintermediary) within an eMarketPlace.

In the following sections we revise the B2B field, with its opportunities andissues. We also provide a description of the emerging B2B XML framework,which are comprehensive set of tools based on XML that are enablers forease of specification, configuration, plug-in, customization, and executionbusiness transactions between business partners over a generic digitalmedium.

6.1.1 B2B: a major business opportunity of business integrationNew business opportunities and strategies make the integration of businessapplications — both new and existing — more and more critical for acompetitive business. The challenge is to achieve integration in the diversecomputing environments that is universal in business today.


The benefits of business integration are most obvious in the context of thefollowing major business opportunities. However, the benefits of suchsolutions 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 andwinning a competitive advantage. And, each requires the integration ofbusiness strategy with IT strategy — business integration.

In each scenario, what is needed is the unification of an improved or changedbusiness 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 marketfaster

• Deriving a single customer view so customers needs can be better served

• Cross-selling products and services through a better understanding ofcustomers buying patterns

• Linking the Web to the company business strategy to reach newcustomers and provide new services to existing customers

• Revitalizing the supply chain to reduce costs and get company products tomarket faster

• Responding faster to business change

In the business integration prospective, the opportunity of the inter-companyintegration (business-to-business) appears to have the much more impact onthe emerging new economy.

In fact, in the new economy, market dynamics will dictate a business modelthat provides for the integration of different partners in a value chain. Using avariety of IT technologies, this model can enable highly coordinated tradingcommunities, each with the ability to operate like a "virtual enterprise".


New business environments demand dynamic and flexible integrationbetween partners in the value chain. While new technologies will be neededto enable such integration, these will need to be able to work seamlessly withexisting inter-company business processes (for example, EDI).

As we will see in this chapter, IBM is currently developing new technologiesdesigned precisely to support this type of business-to-business integrationmainly based on standard technologies such as XML. Business-to-businessis probably the hottest application area of XML.

This chapter describes these technologies, which are a key component ofIBM's Application Framework for e-business, and focus on the strategic rolethat XML plays in building such kinds of infrastructures.

6.1.2 General issues in business-to-business electronic interactionsSeveral issues have to be faced in designing B2B systems. These issues areconcerned with privacy, autonomy, heterogeneity in software and platforms,and more importantly, managing complexity of interactions.

Some of these issues, for example, the heterogeneity of programminglanguages and platforms in which the application components are developed,are also addressed in the automation of business internal processes andintegrating application components. Total knowledge and control in thedesign of the business process within an organization make this amanageable task.

Component architectures such as CORBA and Enterprise Java Beansprovide middleware for integrating application components written in differentlanguages. For the purpose of interaction, an application component needs toknow only the interfaces to other components written in a suitable middlewareintegration language (for example, the Interface Definition Language or IDL inCORBA). In such environments, typically, the applications are executed asshort 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, arenot directly applicable when automating the B2B interactions. First of all, nocommon shared underlying middleware can be assumed for distributedapplications spanning organizational boundaries and using a public networksuch as Internet. Setting up such a common software bus requires tightcoupling of the business partners' software platforms (for example, considerthe issues on security, naming, component registration).

Chapter 6. B2B applications using XML 179

Even if such a software bus can be established, ACID and/or complexextended transaction models of stateful interactions are not appropriate forsuch B2B interactions. First, implementation of such protocols necessitatestight coupling of operational states across business applications, which ishighly undesirable. The application components in one organization may holdlocks and resources in other organizations for an extended period of time,resulting in loss of autonomy. Rollback and/or compensation of applicationsteps is no longer under the control of a single organization. Finally, inreal-world business operations, the operational states always move forward,and explicit recourse actions are taken by business partners to move to amore desirable operational state. An example is cancellation of a priorpurchase or reservation.

The invocation of application components across organizational boundariesneeds to be controlled and monitored. First, without rigorous testing andcooperation in software development across organizations, the correctexecution of such complex distributed applications cannot be assumed.Second, in such automated interactions, trust becomes an overarchingconcern. During runtime, explicit checks are necessary to ensure thatbusiness 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 aB2B interaction via a composable interaction stack based on an electronicTrading Partner Agreements. The automated process of setting up thisinteraction from an unambiguous formal specification and enforcingcontractual agreements is termed an executable Trading Partner Agreement.

These activities are complemented by providing additional services forsupporting long running applications, for example, application development,asynchronous event driven execution, compensation framework, maintainingcorrelation of conversations, logging, and querying the activity on aconversation.

6.1.3 XML B2B frameworks and standardsA B2B framework is a comprehensive set of tools that are enablers for easeof specification, configuration, plug-in, customization, and execution businesstransactions between business partners over a generic digital medium. It isthe gateway, coordinator, and control point of choice across inter-companyprocesses (for example, between the buy/sell component of a local business,the remote businesses, and the back-end systems).


Such kinds of facilities, such as Electronic Data Interchange (EDI), havesuccessfully provided electronic document interchange between companiesand their suppliers for a number of years. EDI has been widely used inindustries like finance and manufacturing since the 1970s. In the USA, ANSIdefined 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 automatingbusiness-to-business transactions. However, EDI’s high cost and inflexiblestructure has always proved a barrier to adoption by all but the largestenterprises. While EDI will continue to evolve, utilizing pervasive networkssuch as the Internet to reduce costs, complementary technologies areemerging, able to provide some of the key capabilities necessary to enabledynamic business process integration. In this new context, small companies,by using the ubiquitous Internet, also want to do B2B transactions with theirpartners using inexpensive off-the-shelf software. Even for a large companywho already has an EDI system, B2B on the Internet should be a goodopportunity for inviting new small partners to join and connect to their owninfrastructure.

A generic B2B framework is based on:

• A common language that can be employed by existing or potential tradingpartners to specify how they will interact (for example, an EDI specificlanguage)

• An electronic contract — a Trading Partner Agreement (TPA) — thatemploys this common language in order to define and enforce theinteraction protocols with which they will do business.

XML B2B frameworks are B2B frameworks which are based on the standardXML technology. During recent months, these facilities have been receivingthe most public attention, since they offer the most potential for businessintegration in the inter-company context. In particular, XML B2B frameworksuse TPA protocols expressed in XML. These are registered to a specializedsoftware component, usually known as a B2B server, along with the internalbusiness processes for setting up such B2B interactions.

Currently, many XML B2B framework specification initiatives have beenstarted and are in various stages of development or still in the planning stage.These initiatives are usually sponsored by independent organizations (andthis is the path followed by IBM), such as the Organization for theAdvancement of Structured Information Standards (OASIS) Consortium(http://www.oasis-open.org) through the XML.org, the XML Industry Portalinitiative (http://www.xml.org), and jointly with the United Nations body for


Trade Facilitation and Electronic Business (UN/CEFACT) through the ebXMLproject (http://www.ebxml.org). The eCo framework specification produced bythe CommerceNet's eCo Working group (eco.commerce.net). In other cases,XML B2B framework standardization activities are promoted by specificcompanies, for example, the Microsoft BizTalk (http://www.biztalk.org), withthe aim to accelerate the rapid adoption of XML in the B2B market.

Table 17 provides a list of the main XML B2B framework standardizationinitiatives:

Table 17. XML B2B framework initiatives

XML B2B Framework Description

XML.org

Web Address:http://www.xml.org

XML.ORG is an industry Web portal operated by the Organization for theAdvancement of Structured Information Standards (OASIS). Funded bya group of companies committed to establishing an open, distributedsystem for enabling the use of XML in electronic commerce and otherindustrial applications, XML.ORG is designed to provide a crediblesource of accurate, timely information about the application of XML inindustrial and commercial settings and to serve as a reference repositoryfor XML specifications such as vocabularies, DTDs, schemas, andnamespaces.

ebXML project

Web Address:http://www.ebxml.org

The United Nations body for Trade Facilitation and Electronic Business(UN/CEFACT) and the Organization for the Advancement of StructuredInformation Standards (OASIS) have joined forces to initiate a worldwideproject to standardize XML business specifications. UN/CEFACT andOASIS have established the Electronic Business XML initiative todevelop a technical framework that will enable XML to be utilized in aconsistent manner for the exchange of all electronic business data.Industry groups currently working on XML specifications have beeninvited to participate in the 18-month project.

Commerce XML (cXML)

Web Address:http://www.cxml.org

cXML is an open XML-based standard created to facilitate e-commercewithin trading communities. The Commerce XML initiative started byAriba Technologies includes among other 40 leading companies in theB2B and B2B fields. cXML is a suite of lightweight XML Document TypeDefinitions (DTDs) and their associated processes that define theexchange of catalog content and transaction information between buyersand suppliers.

Distributed ManagementTask Force

Web Address:http://www.dmtf.org

The DMTF is the industry organization that is leading the development,adoption and unification of management standards and initiatives fordesktop, enterprise and Internet environments. DMTF has taken onenterprise focused industry initiatives and standards such as the WebBased Enterprise Management (WBEM) initiative, the Directory EnabledNetworks (DEN) initiative and pioneered the use of XML as the transportencoding for WBEM.


In parallel with the general XML B2B framework initiatives, the developmentof a large set of “vertical” market vocabularies (connected to a specificindustry sector or cross-industry) has been started during recent years. For alist of organizations known to be producing industry-specific or cross-industryXML Specifications see, for example, the XML.org XML Catalog:http://www.xml.org/xmlorg_registry/index.shtml.

eCo Specification

Web Address:eco.commerce.net

The eCo Specification is an architectural framework that enablesbusinesses to discover each other on the World Wide Web and determinehow they can do business. The eCo framework is a product ofCommerceNet's eCo Working Group, an industry-neutral groupconsisting of experts from over 35 companies and organizationsthroughout the world and is mainly based on XML.

Open Applications Group

Web Address:http://www.openapplications.org

Open Applications Group (OAG) is a non-profit consortium focusing oneasier business software interoperability and is the largest publisher ofXML content for business software interoperability in the world. Amongthe other things OAG defined the Integration Specification (OAGIS) whichis a model for business software application component interoperability.

BizTalk

Web Address:http://www.biztalk.org

Introduced by Microsoft in March 1999, the BizTalk framework makes iteasy for businesses to exchange information between softwareapplications and conduct business over the Internet with trading partnersand customers. The BizTalk framework includes a design framework forimplementing an XML schema and a set of XML tags used in messagessent between applications. Microsoft, other software companies andindustry standards bodies will use the BizTalk framework to produce XMLschemas in a consistent manner to enable integration across industriesand between business systems, regardless of platform, operating systemor underlying technology.

RosettaNet

Web Address:http://www.rosettanet.org

RosettaNet is an independent, self-funded, non-profit consortiumdedicated to the development and deployment of standard electronicbusiness interfaces to align the processes between supply chain partnerson a global basis. Launched in June 1998, RosettaNet is currently in thepilot phase of its implementation cycle.

XML/EDI Group

Web Address:http://www.xmledi.com

The XML/EDI Group was founded in July 1997 in response to PresidentClinton's call for industries' support in dealing with Internet-basedcommerce issues, and the emergence in time and space of pivotaltechnologies that allowed this to be realized through the fusion of XMLand EDI. XML/EDI Group is an ad hoc group of professionals andvolunteers in various industries dedicated to promoting and guiding thefuture of XML/EDI standards and products by donating their time andenergy.

XML B2B Framework Description


These vertical protocols cover particular industrial business transactions thatshould be used within B2B frameworks. They sometimes have the problem ofdefining overlapping or conflicting situations, especially in cases wheredifferent working groups are active in the same business. Some industrygroups are beginning to resolve these differences by promoting protocolmerging initiatives. For example, in the travel industry, the Open TravelAlliance (OTA) decided to incorporate much of the Hotel ElectronicDistribution Network Association specification in the first version of itsstandards.

In the next section, we provide more detailed information on the IBM XMLB2B framework initiative.

6.2 IBM WebSphere B2B Integrator

IBM is an active partner in all almost of the above standardization initiativesand is contributing to expanding the general XML B2B frameworkstandardization basis through the development of flexible electronicdocuments termed Trading Partner Agreements (TPAs). These TPAs operatewithin a specific Business-to-business Protocol Framework (BPF) thatprovides a comprehensive tool set for the specification, configuration,customization, and execution of electronic contracts between businesspartners.

At the time this redbook was written (April 2000) IBM was activating manyinitiatives in the B2B arena. Several alliances with leading companies in theB2B 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 thethree companies will offer advanced open solutions to meet three criticalaspects of accelerating the B2B economy:

• Full-service marketplaces

• Integrated supply chain

• Range of open services

IBM has also announced the introduction of WebSphere B2B Integratorsoftware which will be built on IBM's WebSphere Application Server andMQSeries messaging software, tpaML, and will supply the BPF functionality.

In the following sections we will describe the revision of the fundamentalbuilding blocks on which WebSphere B2B Integrator will be based: TradingPartner Agreements (TPAs) and the IBM Business-to-Business ProtocolFramework (BPF).


Most of the remaining sections are based on the recent tpaML languagestandard proposal that IBM has submitted to the OASIS Consortium, thevendor-neutral organization for XML interoperability, within the XML.ORGinitiative at the end of January 2000. The tpaML has been submitted as adraft to OASIS for potential ratification as a standard. This means that thespecification will be subject to change as the standardization processprogresses. This draft material is highly recommended for more completereading and can be downloaded at the following Web address:http://www.xml.org/xmlorg_resources

6.2.1 Trading Partner AgreementsIBM has recently submitted its Trading Partner Agreement Markup Language(tpaML) for standardization within the OASIS XML.ORG initiative. The tpaMLspecification uses XML to define and implement electronic contracts: TradingPartner Agreements.

The foundation of tpaML is the TPA, which defines how trading partners willinteract at the transport, document exchange and business protocol layers. ATPA contains participant roles (buyers, sellers), communication and securityprotocols and business processes (valid actions, sequencing rules, and soon). XML-based TPA documents capture the essential information uponwhich trading partners must agree in order for their applications and businessprocesses to communicate.

A business uses a TPA document to define the agreed model of interactionwith a specific trading partner. The TPA represents a single long-runningconversation, consisting of a set of related interaction steps, distributed overtime but comprising a single Unit of Business (UOB).

For example, in the context of a conversation between a traveller and a travelagent to arrange an itinerary, a TPA can be used to define and modelallowable interactions between the two actors. That is, a TPA can includeinformation concerning making reservations, modifying or cancelling them,issuing tickets and confirmations, making payments.

One TPA can be used for many independent UOB’s between the sametrading partners — either serially or concurrently. A single TPA can includedefinitions for multiple interaction sequences and multiple message formats,any of which can occur in a UOB instantiated from it. Effectively, a TPA actsas the control centre for all system-mediated interactions with an externalentity.


Over time, the accumulation of TPAs can become an effective repository ofenterprise inter-business process descriptions, providing a major tool forenabling processes enhancements.

tpaML is a complementary technology to specific business protocolstandardization projects such as ebXML, the Electronic Business XMLinitiative, which is a joint effort of the United Nations/CEFACT and OASIS toestablish 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 tpaMLfor potential use with their customers.

6.2.1.1 Principles of B2B electronic Trading Partner AgreementsContracts describe legally enforceable terms and conditions in all kinds ofinteractions between people and organizations. Examples of interactions aremarriage, employment, real estate purchases, and industrial supplyarrangements. In business-to-business applications, there is a need to agreenot only on the traditional terms and conditions but also on IT proceduresfrom communication protocols to business protocols. Today, such contractsare generally written in human languages and then turned into code byprogrammers.

B2B will be given considerable impetus by expressing the IT terms andconditions as electronic TPAs from which the code to perform the terms andconditions can be automatically generated at each party's B2B server. Thiswill speed up the reduction of the terms and conditions to code and ensurethat the code at each business partner's site will accurately embody thedesired terms and conditions. In the longer term, electronic TPAs will alsofacilitate electronic negotiation of terms and conditions, at least for thesimpler situations which need not involve extensive legal negotiation.Electronic negotiation in turn opens the possibility for spontaneous electroniccommerce, that is quick and easy setup of business to business deals on theInternet.

The purpose of the electronic TPA is to express the IT terms and conditions towhich the parties to the TPA must agree in a form in which configurationinformation and the interaction rules which must be executable can beautomatically generated from the TPA in each party's system.

The information in the TPA is not a complete description of the application butonly a description of the interactions between the parties. The applicationmust be designed and programmed in the usual manner. A basic principlewhich governs the TPA definition is the ability to ensure that each party


maintains complete independence from the other party both as to thedetails of the implementations and as to the nature of the business processesand back-end functions (database, transaction monitors, ERP functions, andso 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 thehotel server. That function may, in turn, invoke various site-specific functionsand back-end processes whose details are completely invisible to the otherparty to the TPA. Concerning the independence principle, the TPA neitherrequires, nor provides the means for, ACID transactions involving both partiesthat govern the specific party internal unit of work.

In B2B applications parties act according to the traditional client/servermodel: a client requests services of a server. In the B2B simplestapplications, there may be two parties, one of which is a always a server andthe other, always a client. An example is a travel application involving a travelagency (client) and airline company (server). Even in such a simple case,however, the parties may exchange roles. For example, the airline companymay issue requests to the travel agency for more information about thetraveler or itinerary. Therefore, a much more complete B2B model envisionsapplications in which a given party may play both server and client roles atdifferent times. In other words, a party may both request services of the otherparty and receive service requests from the other party.

To respond to this last requirement, a TPA is represented at each party whichacts as a server by an object, called a TPA object or (or equivalent code fornon-object-oriented implementations), which performs rule checking andtranslation of the request messages from the form defined in the TPA to theactual 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 theinverse translation, from local method calls to the request messages, asdefined in the TPA, which are sent to the other party. A party which can act asboth a client and as a server has both kinds of TPA object.

Figure 53 positions TPAs role within the Business-to-business XMLframeworks.


Figure 53. TPAs within B2B XML frameworks

6.2.1.2 The TPA structureA TPA represents a single long-term running conversation, which is a set ofrelated interactions, dispersed in time, that comprises a single unit ofbusiness (UOB).

For example, in a travel application, the TPA might define the interactionsbetween the travel agent and a hotel company starting with making thedifferent reservations needed by the traveler, to the check-in processesduring the trip, and ending when the traveler checks out at the last stop. Thissequence of steps is a single long-running conversation.

A UOB is performed under the TPA by instantiating the TPA as a long-runningconversation. To perform many UOB, the TPA may be instantiated as manylong-running conversations as is appropriate to the application and theprocessing capabilities of the parties' systems.

Figure 54 shows the main information that a TPA contains.

BPBP

BusinessProcessApplications

Applications

Applications

BPBP

BusinessProcess Applications

Applications

Applications

Trading partnerTrading partner

XML

Passive network Back-end integration

Long running transactions

No shared middleware

Workflow Workflow

TPAs

Back-end integration


Figure 54. The TPA structure

A TPA document contains the following information:

• Overall properties: This includes TPA name, starting dates, and possiblyending dates for validity of the agreement and other global parameters.

• Role and identification: This identifies the parties to the TPA as logicalroles such as buyer, seller, airline, hotel and so on. Specific organizationnames and contact information such as e-mail and postal serviceaddresses are then provided for each role. The allowable actions under aTPA are organized by role making it easy to modify an existing TPA tospecify identical interaction rules but with a different partner. An optionalrole is that of external arbiter for use in resolving disputes.

• Communication and security: These attributes specify communicationand interaction protocols to be used. The specification is layered intotransport, message handling and higher level conversational sections.Protocol choices and parameters for addressing security includingauthentication, certificate handling and non-repudiation are included.

• Actions: For each identified role, this is a menu of the actions that can beperformed on request from the partner. A signature is specified for eachaction defining the parameters and their data types. Sequencing rulesspecify constraints on the order in which actions can be requested.Example actions in the case of the travel agent process interacting with ahotel would be requests to make a room reservation and subsequently tomodify it.

sequencing rules

cancellingrules

actions

TPA

overall properties identification security properties

roles communicationpropeties

Information flow

error handling


• Error handling: Error handling rules manage error conditions (forexample, be the maximum waiting time for the response to a request).

• Commentary: This refers to the text that can be added to the TPA tocover other negotiated — but not processed — issues.

Conceptually, a TPA may be considered to be implemented by a B2B serverat each party's site. The B2B server provides the code for the servicesneeded to support the TPA including the middleware which supportscommunication with the other party, execution of the functions specified in theTPA, interfacing to each party's back-end processes, and logging theinteractions between the parties for purposes such as audit and recovery.The middleware might support the concept of a long-running conversation asthe embodiment of a single UOB between the parties.

6.2.1.3 The tpaML languageA TPA is an XML document from which code is generated at each computersystems of the trading partners and it includes, typically, the list of informationproposed in Figure 54 on page 189. tpaML is the specific mark-up languagethat can be used to write TPA documents.

An XML B2B framework that supports TPA typically has to provide a graphicTPA-authoring tool that understands both the semantics of the TPA definitionand the XML syntax. IBM, for example, is developing the IBM XML VisualXML Builder, which is an XML visual tool including several specialized editingfeatures that can be effectively used to build TPAs. In Section 6.2.4, “Usingthe 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 XMLVisual Builder tool.

As tpaML has specified, this makes it feasible to automatically generate, ateach party's site, the code needed to execute the TPA, enforce its rules, andinvoke the application-specific programs. Many fields in the TPA are thesame in most TPAs; the authoring tools and TPA templates can supply these

Although this book contains extensive details from tpaML, the tpaMLdefinition is still evolving, and many changes will be made, taking intoaccount comments coming from the XML.org working group and othersources. Therefore, the reader is strongly recommended to use theinformation reported here along with the tpaML specification that will beupdated next future. The tpaML specification on which we based theinformation proposed here is the 1.0.3.

Note


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 orXML-Schema file, which defines the tree structure of the TPA tags and someXML syntactic rules but not rules defining specific values of the tags or thesemantic interrelations among the tags. These semantics are defined by atextual design document and are embodied in rules, understood by theauthoring tool, which aid in the creation of a valid TPA.

Overall XML document structureIn 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). Wewill 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 theprocessing of a unit of business (UOB) conversation. These sections form alayered structure somewhat analogous to a layered communication model.

• Business protocol layer defines the heart of the business agreementbetween the trading partners: the services (actions) which the parties tothe TPA can request of each other, and sequencing rules that determinethe order of requests. The Business-Protocol layer is the interface

between the TPA-defined actions and the business-application functionsthat actually perform the actions.

• Document exchange layer accepts a business document from theBusiness Protocol layer, optionally encrypts it, optionally adds a digitalsignature for non-repudiation, and passes it to the transport layer fortransmission to the other party. The options selected for the DocumentExchange layer depend on those selected for the Transport layer. Forexample, if message security is desired and the selected transportprotocol does not provide message encryption then it must be specified atthe Document-Exchange layer.

• Transport layer is responsible for message delivery using the selectedtransport protocol. The selected protocol affects the choices selected forthe Document-Exchange layer. For example, some transport layerprotocols may provide encryption and authentication while others have nosuch facility. Optional functions selected for the Document-Exchange layermust take into account the nature of the transport layer.

The TPA preamble (<TPAInfo>) contains those definitions that areindependent of instantiation, such as TPA name, role definitions, partynames, and TPA duration. In particular, when a given TPA can be repeatedlyreused for different groups of parties, a prototype TPA or template can bewritten in terms of role parameters rather than specific party names. Theauthoring tool can then generate a specific TPA by substituting party namesfor the role parameters and filling in specifics of those parties such as theirelectronic addresses. The role definitions are included under the <TPAInfo>

tag. Each <RoleDefn> tag supplies a pair of role parameter and actual nameThe <RoleName> tag defines the name of each role. The <RolePlayer> tag hasa blank value in a TPA template and the name of an actual party in a specificTPA. Here is the XML for the role definitions for a TPA between an arbitraryairline (@airline) and an arbitrary hotel (@hotel). In this example, the tagsunder <Role> particularize the TPA to an agreement specifically betweenHotelco and Airlineco.

<Role><RoleDefn> 

<RoleName>@hotel</RoleName><RolePlayer>Hotelco</RolePlayer

</RoleDefn><RoleDefn>

<RoleName>@airline</RoleName><RolePlayer>Airlineco</RolePlayer>

</RoleDefn></Role>

When the authoring tool replaces the role parameters by actual party names,it either asks the author for party-specific information or finds this informationin a previously-built database.

The optional comment section (<Comment>) may contain any reference textthat must be included in the TPA.

TPA PreambleThe preamble identifies the TPA and its participants and defines someinvocation-independent properties such as the valid duration. The preambleis defined by the information under the <TPAInfo> tag.

Table 18 lists all types of information that be arranged under the TPApreamble section.

Table 18. The TPA Preamble section

Sub-Section Name XML Tag Description

Identification <TPAName> The TPA is given a unique identificationstring, such as IT14442869

TPA Type <TPAType>

Sub-tags:<Protocol><Version><Type>

This tag provides information about thegeneral type of TPA where the TPA isbased on a defined standard business-levelprotocol such as OBI. It is optional. Itincludes the following information: businessprotocol, protocol version, and protocoltype, stored into specific sub-tags.

A TPA may exist at several different levels of abstraction:

• An abstract description, as it is described in the tpaML specificationdocument, from which any TPA among any parties for any purposecould be derived.

• A prototype TPA (template) between two or more parties for a specificpurpose. This template can be tailored as needed, resulting in aparticular TPA. In the template, one or more parties can be representedby role parameters, such as name, to be replaced by specific parties ina 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 particularlong-running conversation.

Note


Role Definitions <Role>

Sub-tags:<RoleDefn> <RoleName><RolePlayer>

A TPA may be between specific parties orbetween some combination of specificparties and arbitrary parties (roles). This tagdefines the relationships between roles andactual parties. It is optional and should beomitted if roles are not used. A TPAcontaining one or more roles is referred toas a prototype TPA or a reusable TPA. Theresulting TPA, with the roles replaced byspecific parties, is called a fully qualifiedTPA.

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>

This section of the TPA describes all of theparameters needed for person-to-personcommunication between parties to the TPA(for example, mailing address, emailaddress and so on). It should be noted thatthe email address is only for person toperson communications. Specific forms ofaddress are defined in the communicationsection for each of the access protocols.

TPA Lifetime <Duration>

Sub-tags:<Start><End><Date><Time>

This tag specifies the valid duration of theTPA.



Following is the preamble section syntax:

<TPAInfo><TPAName>TPA name</TPAName><TPAType>...</TPAType><Role>...

Invocation Limit <InvocationLimit> This tag specifies the total number of timesthe TPA can be instantiated (conversationscreated) before having to renegotiate it. Ifthe tag is not stated,there is no limit to thenumber of invocations. The value of this tagis a positive numeric string.

Concurrent Conversations <ConcurrentConversations> This tag defines the maximum number ofconversations under this TPA that may beopen at any time. If this tag is omitted, thereis no defined limit though a given servermay have an implementation-based limitand may reject a new conversation if thislimit would be exceeded. The value of thistag is a positive numeric string.

Conversation Instantiation,Closure, and Lifetime

<ConversationLife><TerminateConversation>

A conversation represents a unit ofbusiness (UOB) defined by the businessapplication. Therefore, the businessapplication determines when theconversation is instantiated and closed.From the viewpoint of a TPA betweenparty1 and party2, instantiation takes placeat party1 when party1 sends the first actionrequest to party2. At party2, theconversation is instantiated when itreceives the first request of the UOB fromparty1. Closure of a conversation takesplace when the parties have completed theUOB. The application may use theservice-interface tag<TerminateConversation> to indicateone or more actions whose completionterminates the conversation.

</Role><Participants>...</Participants><Duration>...</Duration><InvocationLimit>number</InvocationLimit><ConcurrentConversations>number</ConcurrentConversations><ConversationLife>time</ConversationLife>

</TPAInfo>

Transport layerThe transport section defines communication protocol, encoding, andtransport security information. Specific forms of address are defined for eachof 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 thedetails 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, maximumallowed network delay, and other parameters.

The tpaML specification document details a set of wide transport protocolsincluding HTTP and HTTPS (for secure Internet interactions) and reliablemessaging such as that provided by IBM’s MQSeries. It is possible to specifythe version of the protocol by using a specific tag.

Following is a list of all communication protocols currently supported or to besupported 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 specificationdocument for details concerning the <communication> section syntax that hasto be used to code information about the various communication protocols.In the following paragraphs, we propose a portion of a TPA XML documentthat uses the HTTP communication protocol between parties and the generalsyntax for HTTP.

For HTTP, each party is individuated by an URL address. Depending on theapplication, there may be one or more URLs, whose use is determined by theapplication. Each <URL> tag provides one URL. The <URL> tag has a requiredattribute, 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 betweenclient and server.s

• The "requestURL" identifies the URL used for receiving requests.

• The "responseURL" identifies the URL used for receiving responsemessages.

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>


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. Thevalue of this tag is a character string.

The <...Node> tag identifies each party and its communication addressinginformation. The name of the node tag is specific to each protocol, in theexample above since the HTTP protocol is used the <HTTPNode> tag isspecified. There is one <...Node> tag for each party. It identifies the partyname using the <OrgName> tag that contains an ID reference attributepointing to the corresponding <PartyName> tag under <Participants> (see theprevious section). All parties must be represented the <Communication>

section including the <Arbitrator>. Under the <...Node> tag is also theunique electronic address of the party: the URL address in our case. Thisaddress is contacted for creating an information-delivery channel. The form ofaddress differs for each communication protocol. Finally, the <NetworkDelay>

tag defines the expected worst-case round trip network delay for anymessage and its response. This delay excludes service time at the recipientof a message prior to its sending a response. Other tags in other parts of theTPA define the service time. There is a unique communication address tag foreach protocol.

The last subparts of the <Transport> section: <TransportEncoding> and<TransportSecurity> sections specify, respectively, how the transport levelencodes messages for transmission (currently, BASE64 is the only choice)and the security specifications for the transport layer of the TPA. This secondtag may be omitted if transport security will not be used for this TPA. Unlessotherwise specified below, transport security applies to messages in bothdirections.

Document exchange layerInformation encompassed in the document-exchange layer includes thename 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 encryptionto 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 definesthe detailed message formats. Examples are OBI and VAN-EDI.

The <MessageEncoding> tag specifies how the messages are encoded by thedocument-exchange level for transmission. Currently, BASE64 is the onlychoice. Either <MessageEncoding> or <TransportEncoding> can be specified,but not both.

The <MessageIdempotency> tag specifies whether all messages sent under theTPA are subject to an idem potency test (detection and discard of duplicatemessages) in the document exchange layer. If the value of the tag is yes, allmessages are subject to the test; otherwise, none have to be specified.

Finally, the <MessageSecurity> tag provides the security specifications for thedocument exchange function. It may be omitted if message security will notbe used for this TPA. Message security may be either non-repudiation ordigital envelope or both.

Business protocol layerThe <BusinessProtocol> tag defines the TPA layer which contains all thebusiness-protocol definitions that support the business application.

Under the <BusinessProtocol> tag is the service interface definition for eachparty that can act as a server. Each service interface contains some overallparameters and the action menu, which includes the set of definitions of theactions 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 actsas a server and the characteristics of the party that is a client. As we will seein the following paragraphs, these services include the list of actions providedby that server, their characteristics, and the actions permitted initially. TheTPA contains a separate service interface definition for each party that actsas a server.

The <ServiceInterface> tag has one attribute, InterfaceId. The value of thisattribute is an alphanumeric string that contains an identifier for this serviceinterface. Each service interface must have an ID that is unique within theTPA. An example is: InterfaceId="SERVER01".

The <ServiceInterface> section syntax is:

<ServiceInterface InterfaceId=id><Client>

<OrgName Partyname=party/>

</Client><TaskName>name</TaskName> <ActionMenu> 

<Action> ...

For some applications, each party may have both server and clientcharacteristics, that is, each party may issue requests to the other party.

Note

</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 severalsubsections. All subsections are intended to address the following basicquestions:

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? (Seethe <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 beterminated? (See the <TerminateConversation> tag)

7. Which is the security level that both server and client sides have to adoptfor exchanging document? (See the <ServiceSecurity> tag)

Among all subsections defined within the <ServiceInterface> tag, the mostimportant one is the Action Menu subsection (the <ActionMenu> tag) whosecontent answers to the question 4 above. We detail the Action Menu in thefollowing section, and refer you to the tpaML specification document for allothers.

ActionsFor each party to the TPA which can act as a server, there is an action menuwhich identifies the permissible action requests and their characteristics.Each action is a unit of work defined in the TPA. It consists of a request forservice and associated information (for example, maximum expectedresponse time for the action). An action may be associated with multiplemessage flows. Some actions can be revoked by corresponding cancelactions defined in the TPA.

Each action is invoked via a request message. During the long executionperiod, the service provider can send one or more informative messages,followed by a final reply message. A completed action can be canceledaccording only to the tpaML specification. An action description also specifieshandling of failures.

We discuss the main elements of an action definition using the followingOpen Buying on the Internet (OBI) protocol buyer action definition. SeeSection 6.2.3, “A sample application TPA” on page 212 for a short descriptionof 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, theinput information, and the result information. In the example above, therequest name is processOBIPOR, that is, the action transmits a purchase-orderrequest to the OBI buyer.

The response to a request is normally by means of one or moreasynchronous reply messages defined by <Response> as in the exampleabove. If <Response> is not provided and for synchronous reply, the clientuses an application-defined query action to obtain the results. The client mustissue a query at a later time to obtain the results. The query is anapplication-defined action that the client application invokes on the server onwhich it invoked the original action. The query request may be dependent onthe specifics of the action request that it supports. A query request to be usedto obtain action results is synchronous.

In the example above, the <Response> tag indicates that the response is bymeans of an asynchronous message from the OBI seller server to the OBIbuyer server and that the response causes the handleOBIPO method to beinvoked at the issuer of the action (here, the OBI seller server). The responsetransmits a completed purchase order (OBIPO).

The <ResponseServiceTime> tag specifies the worst-case service time for theserver (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 isup to the requester's application logic to decide what to do next.

In general, within a single conversation, actions on a given service interfaceare performed sequentially (this is the default behavior). One action may notbe invoked until the prior action is completed. An exception is actions with theattribute type="concurrent". These actions may be invoked concurrently withother actions in the same conversation.

Sequencing rules are used to specify the permissible order of actioninvocations on a given server. The permissible initial action or actions isspecified as follows, specified under the <ServiceInterface> general sectionunder the <StartEnabled> tag.

<StartEnabled><RequestName>action_name</RequestName>

</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.

Within each action definition, a sequencing rule specifies which actions canno longer be invoked following the completion of the particular action, andwhich actions become permissible following the particular action. Thespecification 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 actionwhose definition contains the <Sequencing> tag. The <Disable> tag specifieswhich actions are no longer permitted after this action.

The rules in <Sequencing> are effective only if the action succeeded. If theaction did not succeed, the lists of actions allowed and not allowed areunchanged.

6.2.2 The IBM Business-to-business Protocol FrameworkBusiness-to-business Protocol Framework (BPF) is the IBM implementationenvironment where TPAs can operate.

BPF includes a suite of tools to support the TPA lifecycle, including thepreparation, setup, and generation of new TPA documents, and thegeneration of interaction processing from them. It can be viewed as thegateway, coordinator, and control-point of choice across inter-enterpriseprocesses, for example, between the buy/sell component of a local business,the remote businesses, and the back-end systems (see Figure 55).

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 usinga higher level authoring tool, and are registered to the BPF server along withthe internal business processes for setting up such B2B interactions.

BPF architecture supplies a general mechanism to support various currentstandard business protocols and B2B processes, such as the Open Buyingon the internet (OBI) (see Section 6.2.3, “A sample application TPA” on page212), Commerce XML (cXML) and so on, as well as their futureenhancements. In the BPF architecture, this is accomplished by creating apersonality for a business protocol, based on the specification of a protocolTPA.

Additionally, typical B2B processes, such as Request For Quote (RFQ),Request For Information (RFI), and other processes, are similar acrossvarious B2B protocols and can be implemented by the same framework.

B1

B2

B3

BPF BPF

purchasing selling

BackendSystems

BackendSystems


These other processes can be implemented largely by changing the TPA.Tie-in to back-end systems is provided by invoking an extensibility frameworkfrom the business logic interface which is triggered by incoming requests.

Figure 56 illustrates the generality of BPF for different kinds of businessprotocols. Using OBI as an example (see Section 6.2.3, “A sampleapplication TPA” on page 212 for a short description concerning the OBIprotocol), the middle node in the figure could be a business sell-side OBIserver, with requests coming from the requisitioner (top left); the server onthe left of the picture would then be the OBI buy-side server, and the serveron the top right would be the payment gateway. The local business process atthe (middle) sell-side node could be the fulfillment process, which is invokedusing the BPF framework.

As another example, this figure could be the case of an RFQ process in whichthe buyer (node at the lower left) could submit an RFQ request to theseller/supplier (middle node). The seller would invoke its local businessprocess to determine whether to respond to the RFQ; this may, in turn,involve requests to remote suppliers (on the right), which would be doneusing 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 apurchase order (PO) to the selected seller.


Figure 56. General process flow for BPF

Besides providing the essential services for reliable and secure exchange ofdocuments between business partners based on their agreements, BPFprovides many other services to the applications for handling complexinteractions.

For example, consider a TPA between a buying organization and a sellingorganization. The selling organization may initiate separate conversations,based on separate TPAs, with each of its suppliers for handling servicerequests from its clients. Not only does each conversation have to follow itsassociated TPA, but also, there is also a need for coordination of multipleconversations with different business partners under different TPAs. Forexample, a service request (such as a Travel Plan) can be satisfied only if allthe sub-components can be obtained from different business partners (ahotel, a rental car and so on). A BPF application can express such logic in asimple manner. Each service request can be handled synchronously orasynchronously, depending on the agreement level. An asynchronousrequest may have response time constraints, and associated error handlingrequirements upon time-out.

TPA

TPA

OBI Buyer.............. OBI SellerSeller-SupplierService ProviderAgencyMerchantConsolidator

......Payment Gateway

......Remote Supplier

......Sub-contractor

......Service Provider

......Payment

......


An important characteristic of BPF is that it does not require that all partnersto a given TPA must also use BPF. This independence is essential for doingbusiness over an open medium such as the Internet. One should not dictateto others which technology to use to send and receive messages. BecauseBPF is technology neutral, it is ideal for setting up loosely-coupled tradingagreements in which, for example, a business is free to replace suppliers byothers without having to make a large IT investment to support the newsupplier. As long as the business protocol, and hence the TPA, does notfundamentally change, replacing business partners by others is practical.

The following sections provide a short overview of the basic BPF componentsand the main data flows.

6.2.2.1 BPF components and data flowThe functionality provided by the Business-to-business Protocol Frameworkis layered, as shown in Figure 57, in order to provide different levels ofabstraction for the business data flow. Furthermore, the layering, along withwell-defined inter-layer APIs, minimizes the spread of specialized codeacross the framework. The business data flow through the layers, for anyparticular type of business data, is driven by the Trading Partner Agreementthat governs that particular protocol.


Figure 57. BPF functional layers

The lowest level of the BPF stack is the Transport Layer, which containsprotocol-specific modules that allow the business processes to communicatewith the external world using any of the supported communication protocols,with communication-related security like authentication and encryption. TheTransport Layer interfaces with the Document Exchange layer, whichsupports the abstraction of a business document (for example, an EDIdocument).

The Document exchange layer provides common document-relatedfunctionality such as message data mapping, non-repudiation, time-stamping,logging, and audit-trail. The Document exchange layer interfaces with theBusiness Protocol layer, which provides document-type and trading-partnerspecific 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 settingup the BPF environment and those related to runtime operations for business

overall propertiesrolesidentificationcommunication propertiessecurity propertiesactionserror handlingcommentary

Business protocolsequencing checksresponsiveness checksbusiness logic interface

Document exchangemessage data mappingnon-repudationtime-stampinglogging and audit

Transportnetworksecurity

Business logic

Web application programming environment

TPAB

PF

Layerin

g


to business interactions. Figure 58 shows in a simplified way the BPFcomponent building block architecture and the two component categories:Set up and generation and Run time.

Figure 58. BPF set up environment and runtime operations

Concerning the first category, BPF includes a suite of tools to support theTPA life cycle, including preparation, setup, and generation of new TPAdocuments and the generation of interaction processing from them:

• Authoring tools assist the creation of new TPAs. In many cases, it may beconvenient to construct a new TPA by combining elements from thosepreviously deployed, tailoring the result for the new target interaction. Theauthoring tools for TPA include modelling and template functions tosimplify TPA assembly from pre-existing parts.

• Registration tools are used to populate a registration database withinterface information identifying the user application logic to be bound into

HTTPS

SMTP

MQSeries

EDINetwork

ERPpackages

Workflow

BusinessApplicaiton

DocumentRepository

Transport

DocumentExchanget

RuntimeServices

Interface Code

Rules Code

Network

SubContractors

Run Time

OUTbound request/repliesINbound request/replies

Local Processes

LoggingBPF Manager

ApplicationInterfaces

XML

Parsers

SecurityHandlers

Encoders

RegistrationDatabase

Authoring Tool

Generation Tool

Executable Files

Registration Tools

(a)

(c)

(b)

Set up and generation


the business to business interactions, and user provided helper functionssuch as specialized parsers security handlers and encoders

• Code generation tools use the TPA and information from the registrationdatabase to generate program objects (executables) which, together withthe runtime BPF support, implement the required business-to-businessinteraction processing.

Hence, starting from a TPA authored with the tools described above, andusing a combination of generated and runtime logic, BPF provides a completeimplementation of all message and interaction logic needed for a particulartrading partner interaction. As TPAs are XML based, the strong syntacticchecking available within advanced XML editors can be used in these tools todiagnose and warn of inconsistencies.

At runtime, the BPF Manager uses the data in the registration database andthe generated program objects to manage information flow through thesystem and control execution of the business rules in the TPA. In addition,functions such as event handling, security services, and logging are handledby BPF’s Runtime Services. The BPF generated code enablesinter-enterprise integration, alleviating the need to develop custom programsto manage networking, business event handling, message processing andsequencing.

Generating interaction code from TPAs allows appropriate security validationand message logging steps to be added systematically. Hence, the level ofsecurity is adjusted to the communication context of each business partnerconnection, providing appropriate protection for secure interactions across apublicly accessible network. BPF generated checks for responsiveness of thepartner and valid message sequences improve reliability further.

As noted earlier, to provide an effective single point of consolidation forinteractions, a business-to-business infrastructure needs to provide a broadrange of connectivity options. In addition, it is important to provide servicesfor defining, parsing and manipulating XML messages, together with facilitiesfor importing other message libraries and services. This can simplify themapping of other existing application and message formats both into, and outof, XML messages.

BPF provides many different services to the business applications running onthis platform. In addition to the basic TPA service, BPF provides services liketime-stamped logging, recovery services, public-private key cryptography,reliable document exchange, and document repository.


A version of BPF is built on top of an Enterprise Java Beans server andemploys a diverse set of technologies for providing various functions andservices. For the initial product, WebSphere is used as the EJB server,although there is no specific dependency on WebSphere. A business maycommunicate with its partners using one of several protocols: HTTP, SMTP,FTP, VAN, or IBM MQSeries. It may even use different protocols for differentsets of actions on a per-TPA basis.

Security technologies include transport security (SSL), authentication usingdigital certificates, as well as digital signatures for non-repudiation (usingMD5, SHA-1). Various data formats include EDI, XML-EDI or other XMLformats. Appropriate message parsers or message generators are providedfor converting these documents into an internal format. Independent softwarecomponents providing many of these technologies can be plugged in to theBPF framework via a vendor-neutral open API, thus allowing developers tocustomize solutions of their choice.

6.2.3 A sample application TPAThis section describes an example of the TPA and the server structure for anexisting public protocol: Open Buying on the InternetTM (OBI). OBI is aprotocol for business-to-business Internet commerce. It was designed by theInternet Purchasing Roundtable and is supported by the OBI Consortium(http://www.openbuy.org).

OBI defines the procedures for the high-volume, low-dollar purchasingtransactions that make up most of an organization's purchasing activity. Inthis section, we describe OBI, how it can be described by a TPA, and aschematic view of a possible implementation. Figure 59 illustrates theparticipants in an OBI transaction and the basic information flows.


Figure 59. OBI Participants and flows

The requisitioner is a member of the buying organization (for example, anemployee of a company) and is permitted to place orders directly with theselling organization's merchant server. The requisitioner can browse acatalog and place an order with the selling organization using a browser.

When the requisitioner has placed an order, the selling organization's serversends a partial purchase order (purchase order request) to the buyingorganization's server. The buying organization validates the purchase orderrequest and transforms it into a complete purchase order which it returns tothe selling organization. The selling organization then prepares an invoice orotherwise arranges for payment and ships the ordered merchandise.

The payment authority is an optional part of the system. Its purpose is tohandle electronic payments. Using the browser, the requisitioner can alsoview and update various information at the buying organization server suchas the requisitioner's profile, outstanding requests and so on. Therequisitioner 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 requestand partial purchase order initiated by a requisitioner. This mode might beused, for example, when a purchasing department purchases large volumesto supply a stock room.

ViewPurchasingHomepage

CheckPayment

Invoice

QueryStatus

CatalogBrowsing

PORequest

CompletedPO

Buying Organization

Payment Authority

Requisitioner Selling Organization


In a one possible implementation of OBI, there is a TPA between the buyingorganization and the selling organization, each of which has a business tobusiness 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 TPAbetween buying organization and selling organization. It may interact with thebuying organization and the selling organization in a variety of ways. Theinteraction may be through separate 2-party TPAs between the paymentauthority and the buyer and seller organizations. It may also be simplythrough 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 includesthe specific URLs of the buyer and seller.

• Security information such as the protocol (SSL in this case) and variouscertificate parameters.

• Action menus for the buyer and the seller. The action list for the buyerconsists of one action, "Process OBI Purchase Order Request". Thecompleted purchase order is returned to the seller by means of a callback.The action list for the seller also consists of one action, "Process OBIUnsolicited Purchase Order".

Figure 60 shows the basic system structure and flow of an implementation ofOBI. Shown in the figure are the TPA objects generated from the TPA at thebuyer and seller servers. These objects provide the interfaces betweenvarious processes controlled by the TPA (in particular, the action requests)and the application logic at each server.


Figure 60. The OBI Implementation

The process starts when a requisitioner contacts (1) the buyer server via abrowser and is redirected (2) to the URL for the seller server. Therequisitioner is shown the supplier catalog appropriate to the requisitioner'sorganization.

When the requisitioner makes a selection, the request is communicated tothe TPA object. The TPA object communicates the purchase request to thelocal business processes via one of the gateways shown at the far right in thefigure. 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 buyerserver, sending a partial purchase order to the buyer server.

This request arrives at the buyer's TPA object, which evaluates the rulesdefined in the TPA and then sends the partial purchase order to the buyerapplication logic. In processing the partial purchase order, the applicationlogic communicates with local business processes, via the gateway shown atthe lower left in the figure, to request approval (4) of the purchase order.

Requisitioner

Catalog andpurchasing functions

Gateway

Gateway

Lo

calP

roce

sses

Business-To-Business Manager

TPAObject

Request PO

Partial PO

Completed POTPAObject

GatewayLocalProcesses

ApplicationLogic

Business-To-Business Manager

2. Redirected topreferred suppliercatalog

1. Login

3. Partial PO

5. Completed

PO

Partial PO

Completed PO

4'. Confirm4. RequestApproval

Selling

Organization

Buying Organization


If the purchase is approved (4'), the approval arrives at the application logic,which completes the purchase order and passes the completed purchaseorder 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, whichpasses it to the local processes via the gateway at the lower right. The localprocesses handle fulfillment (for example, shipping) and invoicing/payment.They also initiate a confirmation message to be returned to the requisitionervia the browser (not shown in Figure 60).

In the following section we will build an OBI TPA XML document whichdefines the OBI between two specific companies: Large Co, which plays thebuyer role, and Pens Are We, which plays the seller role, as proposed in thetpaML specification document.

To construct this particular TPA we will use IBM XML Visual Builder tool whichis, as described in Section 3.2.3.3, “Visual XML tools” on page 69, an earlytechnology release for providing XML tooling in the IBM ApplicationFramework 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 TPAThe IBM Visual XML Builder is a tool for constructing valid XML documentsfrom a DTD, and can be effectively used to build Trading PartnerAgreements. 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 suchas 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 semanticinformation.

• Generate the final XML document.

An important feature of the IBM Visual XML Builder is concerned with theability to promote the separation of roles and responsibilities in a largeorganization. In particular, the tool can be used by people creating an XMLstructure from scratch using a DTD, or it can be used by people customizingan existing XML template/model by simply filling in the values. Different


services will be available to the user depending on what mode the tool isinvoked in.

This last feature is particular useful in the context of the TPA building processsince it is possible to foresee that within an organization/company there areseparate responsibilities and roles to define and handle TPAs. It is possible tohave separate roles and responsibilities which include the TPA XML modeldeveloping process and the TPA XML document building process with aspecific partner. In the first case, a general TPA XML model can include sometypes of relationships within a partner, such as a buyer to supplier, and somebusiness protocol. In the second case, a TPA model is customized to matchthe agreements in place with a particular partner.

6.2.4.1 Getting started with the IBM XML Visual BuilderEach tool in the IBM XML Tools package operates through models. A modelencapsulates the tool state, or what is commonly known as meta-data,concerning the particular object produced by that tool (a DTD, an XML, andso on). For example, as a first step for creating an XML document, it isnecessary to have a model of the XML document that has to be created. AnXML model, for instance, contains additional meta-data that are not capturedby a DTD and are used by the Visual tool. An XML model is created from aspecific 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 formatto externalize each tool's meta-model.

This operational approach of the IBM XML tools influences positively the TPAbuilding process. In particular, to build a specific TPA XML document byusing the IBM XML Visual Builder, these steps must be followed:

1. Generate a General TPA XML model (if not available) starting from thetpaML specification DTD document. This model can be generated byusing, for example, the IBM Visual DTD tool also included in the packageor 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 particularTPA XML document that has to be built. The TPA XML model can alsoinclude other sub-models (2a), define tags default values, and defineuser-exits on tag attributes values for specifying an external applicationspecific processing logic that can be activated during the generation ofXML documents from that model (2b). The external processing logicdetermines on-the-fly the particular tag attribute value to be set when theXML document is generated.


3. Edit and generate a valid TPA XML document by using the TPA XMLmodel built and customized in step 2.

Figure 61 shows, schematically, the various products generated during theTPA XML document building process within the IBM XML Visual Builder toolenvironment.

Figure 61. TPA XML document building process within IBM Visual XML Builder

Figure 62 shows the wizard window that IBM Visual Builder tool presents tothe user when it is asked to create a new XML model. The figure proposes, inparticular, a moment at the beginning of step 2, where we are building thespecialized TPA model that will encapsulate the structure of the contractbetween our two companies: Large Co and Pens We Are. We defined, inparticular, the TPA model name (C:\IBMXMLTools\xmimodels\OBI.xml.xmi) andspecified to be used the general TPA XML model (tpa.dtd.xmi) we builtstarting from the tpaML DTD specification during step 1.

tpaMLDTD

General TPA XMLmodel1.

Specific TPA XMLmodel2a.

TPA XML Documents3.

2b. Other XML modelsor sub-models 2c.

ExternalProcessing Logic


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 XMLBuilder requires the user to specify the root element of the XML documentthat has to be built (see Figure 63). All elements available in the tpaML.DTDspecification can be selected. For building a TPA XML model, the TPAelement has to be selected.

Another important feature of XML Visual Builder is that by getting asub-element from an existing TPA model (for example, Address,Communication, and so on), another TPA model can be built using thatsub-element as a new root. As we will show in the following sections, we canbuild models for each sub-part of a TPA contract (that is, sub-models; seestep 2b above) and after this, insert/include all sub-parts into a general TPAXML model.


Figure 63. Selecting the XML document root element

Figure 64 shows the IBM XML Visual Builder main window after the specificTPA XML model creation process, which reflects the fact that the OBI TPAstructure for our contract is completed (step 2a). On the left side of thewindow, a tree view is displayed which shows a document structure reflectingthe basic tpaML.dtd encapsulated in the General TPA XML model.

We are now ready to use the editing facility provided by IBM XML VisualBuilder tool to customize the specific TPA XML model for building anOBI-based TPA model that will supply the skeleton of the XML document(contract) between our two companies. In particular, we will customize themodel according to our requirements by deleting unnecessary optional tagsand/or duplicating tags into the model.


Figure 64. TPA document structure

6.2.4.2 Customizing the TPA XML modelIn this section we will customize the TPA XML model in other to reflect thespecific OBI agreement details between the Large Co and Pens We Arecompanies. We will collect all need information by following the tpaMLspecification minimal requirements.

To collect information and design the corresponding TPA XML model, we willfollow a step-by-step approach arranged around the basic TPA layers:General Information layer, Transport layer, Document Exchange layer, andBusiness protocol layer.


In the next section we will refine the TPA XML model by adding furthermeta-data that are handled by the IBM XML Visual Builder which can help incomposing and generating the final TPA XML document.

Contract general information:Start: 01/01/1999, 00:00:00End: 01/01/2001, 00:00:00Number of invocations: 100000Number of concurrent conversations: 1Conversation Life: 86400s

Buyer details:Large CoTel. 914-945-3000Address: Large Co

HQ Building1 Main StreetSmallTownNY10000USA

Address for billing:Large CoAccounting Department100 Bean Counters RoadAny CityCT06000USA

Address for shippingLarge CoProcurement Department99 Purchase RoadBuy CityNY10001USA

Primary contact:Smith L. JohnSenior BuyerTel. 914-111-6789Tel. 914-111-6790email: [email protected]: http://www.largeco.com/procurement/jsmith.htmlfax: 914-111-6780

Secondary Contact:


Blow J. JoeBuyerTel. 914-111-6722Tel. 914-111-6725email: [email protected]: 914-111-6780

Seller details:Pens Are WeTel. 945-123-1000Address: Pens Are We

Building 001123 High StreetEarthQuake CityCA94567USA

Contact: Doe E. JaneVice President of Internet SalesTel. 945-123-4567Tel. 945-123-4570email: [email protected]: http://www.pensarewe.com/sales/jdoe.htmlfax: 945-123-9999

Arbitrator details:XYZArbitratorTel. 780-333-1111Address: XYZArbitrator

Suite 377 Lawyers BlvdABC CityMA01234USA

Contact: Mr. Black K. JoeTel. 780-333-4040Tel. 780-333-4045email: [email protected]: http://www.xyzarbitrator.com/jblack.htmlfax: 780-333-5000

Figure 65 shows the proposed TPAinfo section of the TPA XML model forcoding the general information layer between Large Co and Pens We Are. Asyou can see from this figure, the initial TPA XML model has been simplified bydeleting, in some cases, unnecessary elements (for example, the Role and


Comment tags), and by duplicating elements when needed in other cases.We also added a new Member element in the Participants section, andseveral 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 nodeParty Name LargeCo

URLURLName: requestURL


Address: https://www.largeco.com/jackal/servlet/OBIBuy

Second HTTP nodeParty Name PensAreWe

URLURLName: logOnURLAddress: https://www.pensarewe.com/coyote/servlet/OBILogon

URLURLName: requestURLAddress: https://www.pensarewe.com/coyote/servlet/OBIsell

URLURLName: responseURLAddress: https://www.pensarewe.com/coyote/servlet/OBIsell

NetworkDelay:300s

Security:

EncryptionProtocol: SSLVersion 3.0Certificate: X509.V3KeyLength: 1024Party Name: LargeCoIssuer Name: VeriSign, Inc.Issuer Certificate Source: http://www.verisign.com/certsParty Name: PensAreWeIssuer Name: GTE, Inc.Issuer Certificate Source: http://www.gte.com/certs

AuthenticationProtocol: SSLVersion: 3.0Certificate: X509.V3KeyLength: 1024Party Name: LargeCoIssuer Name: VeriSign, Inc.Issuer Certificate Source: http://www.verisign.com/certsParty Name: PensAreWeIssuer Name: GTE, Inc.Issuer Certificate Source: http://www.gte.com/certs

Figure 66 shows the proposed Transport section of the TPA XML model forcoding 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 beensimplified by deleting, in some cases, unnecessary elements (for example,


the Transport Encoding tag), and by duplicating elements when needed inother 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: OBIMessage encoding: BASE64Message idempotency: yes

MessageSecurityType: Non RepudiationProtocol: Digital Signature


Hash Function: M D5Encryption Algorithm:RSASignature Algorithm: DSACertificate Type: X509.V3Key Length: 1024Party Name: LargeCoIssuer Name: VeriSign, Inc.Issuer Certificate Source: http://www.verisign.com/certsParty Name: PensAreWeIssuer Name: GTE, Inc.Issuer Certificate Source: http://www.gte.com/certs

Figure 67 shows the proposed DocExchange section of the TPA XML modelfor coding the Document exchange layer between Large Co and Pens WeAre. Also, as you can see from this figure, the initial TPA XML model hasbeen simplified by deleting, in some cases, unnecessary elements (forexample, the Digital Envelope tag in the Message Security tag), and byduplicating elements when needed in other cases. We also added a newParty element in the Certificate section.


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: 3600sPresume: fail

ActionsAction 1.

Request Name: putOPORRequest Message: OBIPORResponse Name: getOPOResponse Message: OBIPO

Start Enabled ActionsRequestName: putOPOR


Pens Are We Services (Large Co is acting as client)Response Service Time: 3600sPresume: fail

ActionsAction 1.

Request Name: shopRequest Message: shopMessage

Action 2.Request Name: putOPORequest Message: OBIPO

Figure 68 shows the proposed BusinessProtocol section of the TPA XMLmodel for coding the Business Protocol layer between Large Co and Pens WeAre. This section defines the services provided by a party that acts as aserver and the characteristics of the party that is a client. In our case, LargeCo plays the buyer role and Pens We Are plays the seller role, in the contextof the OBI application previously described.

Both parties expose services to the other side (one service from Large Coand 2 services from Pens We Are, respectively). The initial TPA XML modelhas been simplified by deleting, in some cases, unnecessary elements (forexample, the Responses tags in both Pens We Are action tags), and byduplicating elements when needed in other cases. We also added a newServiceInterface element in the BusinessProtocol section just for coding inthis TPA both services sides.


Figure 68. Service Interface section of TPA XML model for the two companies


6.2.4.3 Adding further meta-data to the TPA XML modelIn this section we will refine the basic TPA XML model built in the previousone by adding further meta-data that are handled by the IBM XML VisualBuilder which can help in composing and generating the final OBI TPA XMLdocument.

IBM XML Visual builder supplies several meta-data facilities. In particular, wecan add to the basic TPA XML model, as additional semantic informationand/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 specificprocessing logic.

• Reuse of other TPA XML sub-models.

A certain “role separation” support can characterize the XML TPA buildingprocess within IBM XML Visual Builder, as mentioned at the end of Section6.2.4, “Using the IBM Visual XML Builder for a specific OBI TPA” on page216. According to this role separation, once a TPA XML model is created, wehave a very informative skeleton for building, not only a specific TPA XMLdocument, but rather a “class” of TPA XML documents that can differ fromeach other for specific parameter/attribute contents.

In our case, for example, our main initial aim was to build a specific TPA XMLdocument between Large Co and Pens We Are companies implementing theOBI protocol. However, if we imagine that this activity were carried out, forinstance, by Large Co IT experts, it is foreseen that once the TPA XML modelis built, it can be used to generate new similar TPA contracts between LargeCo and other seller companies implementing the same business protocol.

Thus, in the Large Co company, two groups of people with different roles canwork on the TPA authoring process: the TPA XML model authors and the TPAXML document authors. The second group has only the responsibility to takethe results of the first group, a TPA XML model, fill in specific values, andgenerate TPA XML documents. The second group of people is not concernedwith changing the structure of a model, it only provides data to the model sothat a final TPA XML document can be generated.

IBM XML Visual Builder tool is architected in such a way that it can be runaccording 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 Restrictedmode, which supplies a restricted editing facility.


Figure 69 shows that in the TPA XML model, we have associated to theDate 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 XMLVisual Builder. Users can add to the tool specific plug-in mechanisms,encapsulated into JAVA classes, for generating specific field values. User-exitfunctions will be called before the actual XML document is generated. In thecase of TPA, IBM XML Visual Builder supplies a specific JAVA class(com.ibm.b2b.vxml.tpa.TPAMemberId) which calculates automatically theMemberId field value when the final TPA XML document will be generated.Additionally, in the IdCodeType field, we put the special value ZZ and definedit in the tpaML specification which denotes any mutually agreed identifier. Inthis 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 andBradstreet registry.


Figure 70. Using the user-exit function in IBM XML Visual Builder environment

6.2.4.4 Editing and generating the OBI TPA XML documentLast step in the TPA building process consists in filling in all TPA XML modelelements with specific contract values and generating the final TPA XMLdocument. In doing this operation we can open, with the IBM XML VisualBuilder, the TPA XML Model created in the previous sections in the Restrictedmode and for each field proposed in the model, fill in the specific value.


As Figure 71 shows, IBM XML Visual Builder supplies a simplified editingfacility that speeds up the TPA XML document filling process. In this figure,IBM XML Visual Builder is using specific meta-data we associated to theParticipants section in the TPA XML model for driving the section fillingprocess. All Participants section sub-elements are shown as a group ratherthan as individual fields for the data entry. Editing the sub-elements as agroup 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 specializedcalendar editing window.


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 TPAXML document. Figure 73 shows a portion of the OBI TPA XML sourcedocument. Appendix A, “An example of a OBI TPA XML document” on page281, lists the full OBI TPA XML document.


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 inthe business-to-business application context, as well as what IBM is doing inhelping companies in this particular field.

B2B applications have been positioned as one of the best opportunities of theemerging business integration IT field in the inter-enterprise e-businessapplication area.

Two key IBM technologies, recently introduced, that can support the B2Bbusiness models have been extensively described: the standard languageproposal tpaML and the Business-to-business Protocol Framework (BPF).


These technologies are the basic building blocks of IBM WebSphere B2BIntegrator, the B2B XML-based framework announced by IBM.

tpaML is the standard mark-up language proposed by IBM for writing TradingPartner Agreements (TPAs). A TPA is an XML document that contains thegeneral contract terms and conditions, participant roles (buyers, sellers),communication and security protocols and business processes, (validactions, sequencing rules, etc.). TPA documents capture the essentialinformation upon which trading partners must agree in order for theirapplications and business processes to communicate.

BPF provides a comprehensive set of tools and enablers for ease ofspecification, configuration, plug-in, customization, and execution of a set ofTPAs between business partners. It is the gateway, coordinator, and controlpoint of choice across inter-enterprise processes. Examples of usage of TPAand TPA authoring tools have been also provided.


Part 3. B2B eMarketPlaces

In this last part of the book, we provide a case study, which is anexample of an XML-based e-business application that covers both thebusiness-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 anddevelopers understand what issues need to be considered during theimplementation of an e-business system, as well as how to implementthe main components using XML technology and, when available, IBMproducts.

Chapter 7, “B2B eMarketPlaces: a case study” on page 241 proposes anew project called “B2B eMarketPlace intermediary” (or E-broker) thatcan intermediate on the Internet between trading partners such asbuyers and sellers operating in a common eMarketPlace. The onlineintermediary establishes businesses between buyers and sellers bycombining services and data dynamically and appropriately accordingto specific intermediary business models. We introduce the case studyin detail, giving an overview of the B2B eMarketPlace business areaand proposed services, and we also characterize the main features ofthe application.

The chapter presents the architecture of E-broker, identifying the maincomponents, relations between them, and the interfaces of the system.It shows what roles XML technologies play in the application, what keyissues should be considered during the design of the system, and whatIBM products can be used to implement the application.


Chapter 7. B2B eMarketPlaces: a case study

In this chapter we propose a new project called “B2B eMarketPlaceintermediary” (or E-broker) that can intermediate on the Internet betweentrading partners, such as buyers and sellers, operating in a commoneMarketPlace. The online intermediary establishes businesses betweenbuyers and sellers by combining services and data dynamically andappropriately according to specific intermediary business models. Weintroduce the case study in detail, giving an overview of the B2BeMarketPlace business area and proposed services, and we alsocharacterize the main features of the application.

This chapter presents the architecture of E-broker, identifying the maincomponents, relations between them, and the interfaces of the system. Itshows what roles XML technologies play in the application, what key issuesshould be considered during the design of the system, and what IBMproducts can be used to implement the application.

7.1 Why the B2B eMarketPlace application?

B2B eMarketPlace intermediaries are strongly emerging in the B2B market tocomplement and empower the traditional B2B model centered around thebuyer-seller transaction paradigm. B2B eMarketPlace intermediariesmediate among buyers and sellers by facilitating the business transactionprocess and, in some cases, by supplying value-added function to thebusiness transaction chain. B2B eMarketPlace intermediaries define abusiness-to-marketplace-to-business (B2M2B) model which extends B2Bapplications and technology. The M represents the eMarketPlaceintermediary or online trading communities which assists multiple buyers andsuppliers to exchange information and transactions.

We decided to select the B2B eMarketPlace field, as the main B2B casestudy of this book, since it encompasses and at the same time extends alltraditional B2B (but also B2C) related issues. B2B eMarketPlace applicationsoffer many interesting aspects to analyze and discuss from both the projectand the design point of view, as well as the role that XML plays in these typesof systems. In particular, this type of application gives you a chance tounderstand in practical terms many more elements in applying XML thansimply analyzing a traditional B2B or B2C application example.


7.2 eMarketPlaces and online intermediaries

The traditional B2B model, centered around the buyer-seller transactionparadigm, is showing its limitations: it is definite in scale and displays onlypartially efficiency in terms of market economics. Recently, to overcomethese limitations, a new Internet business model appeared which supportsB2M2B and leverages existing B2B applications and technology. The Mrepresents the eMarketPlace or online trading communities which assistsmultiple buyers and suppliers to exchange information and transactions.

eMarketPlace are Internet based hubs that focus on specific industry verticalsor specific industry processes and use various market making mechanisms(auctions, exchanges, aggregation) to mediate any-to-any transactionsamong businesses.

Through the eMarketPlace hubs, buyers and sellers can trade electronicallywith established partners and at the same time get access to new marketsand new parts of the supply chain. eMarketPlaces can be public, where allmembers participate in an open, interactive buying and selling community, orprivate, which are invitation-only communities whose members participate inspecial 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 intermediarycompany/organization, which is a third party that combines enabling B2Btechnology along with market-specific or process specific expertise tofacilitate trade. B2B eMarketPlace offerings are being built and operated by anumber of different parties, including:

• Major industry players: For example, Ford, General Motors andDaimlerChrysler in the automotive sector recently announced plans tolaunch a B2B procurement systems mega market for suppliers. Sears andCarrefour — a French retailer and one of the world's largest — areestablishing an eMarketPlace to handle ordering, inventory and eventuallythe entire purchasing process. Sabre Holdings Corp. announced anInternet-based, businesses-to-business trade exchange for the travel andtransportation industry. Boeing, Lockheed Martin, Raytheon, and BritishAerospace will form an eMarketPlace in the Aerospace sector aiming toconnect a massive number of suppliers and buyers in that industry, andallowing them to buy and sell parts and conduct business over theInternet.

• Industry associations: For example, the Association of Unit Trusts andInvestment Funds (AUTIF) in UK funded the industry’s electronic tradinginitiative, EMX, to manage a new electronic commerce services.


• Systems integrators: For example, IBM Global Services launchedComponent Knowledge which is a B2B hub for the electronic componentsmarket.

• Software providers: For example, Commerce One, Ariba, andSystemcare. Ariba proposes an Internet Business Exchange service whichis a hosted Internet service that enables corporations and Net marketmakers to quickly build electronic marketplaces powered by the AribaNetwork platform, without installing or maintaining their own eCommerceinfrastructures.

The general aim of B2B eMarketPlace is to resolve the concerns thate-commerce poses for buyers and sellers coming together with no previoustransaction history. The role of the intermediary comprehends areas ofcommunication, commerce, and content, and includes:

• Bringing together buyers and sellers within a common eMarketPlace

• Providing methods for transactions to take place, for example, through anauction and standard contracts in order for them to be cleared.

• Characterizing buyers and sellers; for buyers, they provide assurance thatsellers have suitable goods, by tracking levels of service quality; forsellers, they provide assurance that the buyers are capable of makingpayments

• Aggregating third party content

• Creating original content through aggregating trading data and user data

• Providing value added services such as insurance, logistics, and financingthrough partnerships with third parties

• Targeted communication through offering e-mail, alarms and alerts andpersonalization of advertising and content

• Supporting buyers and sellers in accessing to the eMarketPlace

Figure 74 shows the eMarketPlace formed by online intermediaries andtypical mediation roles.

Chapter 7. B2B eMarketPlaces: a case study 243

Figure 74. The eMarketPlace and the online intermediary business models

In the following section, we revise some typical business models which areadopted by B2B online intermediaries.

7.2.1 B2B online intermediary business trading modelsB2B online intermediaries make use of a number of business models toenable trade among parties to the eMarketPlace. The most common businessmodels are the following:

Directories

The Directory mechanisms are very similar to the well known yellow pagesservice. By using this service buyers and sellers have the chance topromote themselves in the eMarketPlace and, at the same time, to exposethe list of services and the types of contracts that they accepts. Businesstransactions can take place between buyer and seller pairs independentlyfrom the intermediary.

Bus

ines

sM

odel

s

BuyerBuyer

Buyer

SellerSeller

Seller

B2Bintermediary

Auctions

Exchanges

Aggregations

Added value services

Directories

MarketP

lace


Auctions

Auctions provide mechanisms which temporary match buyers and sellersand prices to levels of supply and demand. Auction services are typicallydelivered as: Bulletin boards (sellers post offers and buyers bid on theseoffers the bidding period is not defined: offers and bid are valid until areremoved from the bulletin board and bidders are not aware of otherpeople’s bids), Reverse auctions (traditional auction mechanism in whichbuyers post requests to purchase in a structured format, and sellers to bidfor supply of the goods or services), Regular auctions (traditional auctionmechanism 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 forsome underlying commodity. These exchanges replicate what has beendeveloped in industry specific financial exchanges and in the physicalmarket (buyers, trade houses, exporters, producers). Differently fromauctions, offers can be made at any time and can often be withdrawn orrevised.

Aggregation

In this intermediary business model intermediaries play an active role byaggregating requests coming from the various parties. In particular, wecan distinguish the aggregation model into three forms:

Selling aggregation. Intermediaries aggregate, standardize and indexsuppliers catalogues or content and make these available in a centralizedlocation to buyers.

Buying aggregation. Buyers requests for quotes (RFQs) are aggregatedand linked into a pool of suppliers who can make bids.

Content aggregation. Online intermediary publishers aggregate and filterthird party content and combine this with proprietary content to attractcommunities of industry professionals.

Added value services

The last and much more specialized intermediation business model seeintermediaries playing an active role in the business process transaction.Intermediaries provide in this case value added services that complementor complete the business transactions between parties.

Typical value-added services range from Finance (managing transactionprocessing systems), Fraud services, Credit Checking Services, Billpresentation and payment, Logistic, Export control services.


In the following sections, we propose the project of an B2B eMarketPlaceonline intermediary: E-broker, which targets some of the intermediation areasand business models introduced above.

7.3 The E-broker application

This section focuses on the general requirements and the macro-design ofthe E-broker B2B online intermediary. E-broker is to be thought of as the mainIT XML-based backbone that can support B2B vertical eMarketPlace hubs.Thus, the design and project considerations explained below need not berestricted to a particular application domain (automotive, chemical, foods,and so on); rather, the main E-broker building blocks can belong to andcharacterize any type of B2B online intermediary.

E-broker’s main aims are the following:

• Qualify and bring together buyers and sellers within a commoneMarketPlace

• Provide a set of business models for transactions to take place betweeneMarketPlace 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-sideor the seller-side. Typical scenarios that we foresee for building and operatinga B2B vertical eMarketPlace hub that uses the E-broker IT infrastructureinclude any of the following:

• Spin-offs from existing industry players, or start-ups with expertise in aparticular industry segment (insurance, finance, foods, and so on)

• Service and outsourcing IT providers, for example, Application ServiceProviders (ASPs) or large IT service providers that want to create new anddomain-oriented business models

• Independent industry associations that can leverage the quantity and thequality of trading operations between their associates

There are several alternatives that one can follow to design and implementthe E-broker architecture. Using an XML-based infrastructure is just onepossibility; it may even be the best one! Nevertheless, our main aim in doingthis case study has not been to show how to project and design this particulare-business application, but to check the feasibility of using XML in such an


e-business infrastructure. Thus, our prerequisites in designing E-broker arethe 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 supportedby E-broker, and in the following section we analyze the impact of XML indesigning the E-broker IT infrastructure.

7.3.1 E-broker business modelsE-broker implements some of the general business models supported byonline intermediaries and described in Section 7.2.1, “B2B onlineintermediary business trading models” on page 244. In particular, we imaginethat the E-broker IT infrastructure that implements the intermediary businessmodels will be appropriately customized for operating into a specific verticaleMarketPlace, and from an abstract point of view, the basic business modelscan be arranged into the IT infrastructure in approximately the same wayacross 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 providesspecialized eMarketPlace Information Portal and Customer Support services.The eMarketPlace Information Portal delivers specific market and communitynews and analysis, general and personalized information, and so on, to thetrading community. Through the Web, Customer Support services facilitatethe 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 indetail. Figure 75 depicts the E-broker eMarketPlace. As this figure shows, theeMarketPlace is accessed not only by traders (buyers and sellers) but alsofrom other eMarketPlaces and E-broker partners (banks, logistic companies,and so on) that can supply value-added services to the trading community.


Figure 75. The E-broker eMarketPlace

Advanced B2B directory service

According to the first business model, E-broker handles the list of allparties that have access to the eMarketPlace. It is responsible to acceptonline subscriptions, and to monitor and qualify the parties that enter intothe eMarketPlace.

For each party that gains access to the E-broker space, E-broker stores aparty profile. The party profile consists of two main sub-sections: ageneral business information section and a specialized business profilesection.

- The first section includes the party identification details, the party’sbusiness classification, and the catalogue of services or goods ofinterest, and so on.

- The business profile section includes relevant information on how tocompose standard Trading Partner Agreements. These agreementswill rule how transactions will take place. The business profile incudes,among other things, the party security profile, the preferred arbitrator,

Buyer Buyer

Buyer

SellerSeller

Seller

B2B DirectoryService

InternetAucions

AggregationsE-broker other eMarketPlaces

eMarket InformationPortal Customer support

servicesE-broker partners(banks, logistic,

etc.)


the preferred transport, document-exchange, and business-protocollayers, as well as the set of standard TPAs accepted.

E-broker supplies appropriate Web-based facilities to query the directorycontent and navigate through the party information according to severalsearching criteria.

Additionally, we envision the directory service integrated with an advancedTPA authoring tool. This TPA authoring tool supplies to a party that wouldactivate a specific trading partnership with a candidate trading partner aremote facility to select a candidate trading partner standard TPA and/orTPA requirements defined in the party business profile and compose newand specific contracts.

Once contracts are generated (E-broker can also generate the specificTPA runtime code), these can be downloaded in the party’s site, andbusiness transactions can take place according to the contracts betweenthe IT systems of the parties involved in a contract without the E-brokerintermediation or, in case it is not possible to have a direct connectionbetween parties, through the E-broker IT infrastructure. In this last case,E-broker can also supply value-added services (for example, a translationof the message flow) to the two parties.

Figure 76 shows the interactions that are activated during the initialsubscription process and during a trader profile update activity. A trader(labeled Trader in the figure) connects to the E-broker and sends asubscription request (1). All subscription requests are evaluated by theE-broker operators (2 and 3), and eventually a communication ofacceptance is returned (4). Once accepted, a trader can update and/orcomplete his profile (5).


Figure 76. Interactions between Traders and the E-broker Directory Service

Figure 77 shows interactions that are activated during the online buildingprocess of new TPAs. A trader (Trader A in the figure) connects to theE-broker Directory service and query the trading partners repository(1 and 2). Once a trading partner (the Trading Partner B in the figure) isfound, the trader starts to compose the new TPA by using information comingfrom its business profile, from the candidate trading partner business profileand from the TPA standard repository handled centrally by E-broker (3). Oncethe new TPA is finished, the trader can download it (the XML document or aTPA runtime version) (4) and start a B2B transaction with the new tradingpartner (5).

E-broker

Trader

1. SubscriptionReq.

PartyProfiles

4. ConfirmSubscription Identification Business Profile

Party Profile

nameBusinesssegmentcatalogue

standard TPAacceptedstandardconditionsaccepted

Adminstrator

5. Profile Update

2. Subscription Req.

3. Confirm SubscriptionDirectoryService

5. ProfileUpdate


Figure 77. TPA online building process

Auctions

E-broker supplies a set of auction mechanisms. In particular, all threebasic auction modalities reviewed in Section 7.3.1, “E-broker businessmodels” 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 canbid on these offers. The bidding period is not defined: offers and bidsare valid until they are removed from the bulletin board, and biddersare not aware of other people’s bids.

- A reverse auctions service where buyers can post requests topurchase in a structured and controlled format, and sellers will bid forsupply of the goods or services.

Trader A

1. BrowsingDirectory andselectiongpartners

4. DownloadTPA3. Composing

a new TPA

E-broker

PartyProfiles

DirectoryService:remote TPAautoring tool

StandardTPA repository

Trading Partner B5. B2B Transaction

2. Query

Business ProfileTrader A

Business ProfileTrader B

Standard TPA


- Regular auctions service where sellers can post an offer and buyerscan bid on it.

E-broker plays an active role in the auction process. Buyers and sellershave to sign specific Trading Partner Agreements with E-broker andsubmit bids or offers by appropriately connecting their IT infrastructureswith the E-broker IT infrastructure according to the TPA. Also, in this case,E-broker provides advanced TPA authoring tools (wizards) that will beused by the parties that would have access to the auctions.

Evidently, the usage of TPA supplies a means to fully automatize theentire Offer-Bid auction cycle.

Figure 78 shows a typical information flow that is set up for the bulletinboard auction mechanism. Sellers (labeled Seller in the figure) post offerson the bulletin board (1), and these remain on the bulletin board until aspecific (6) remove action is invoked. E-broker, eventually, can inviteinterested buyers to formulate bids (2). Buyers (labeled Buyer in thefigure) can browse and post bids for the offers currently opened (3),asking for offer details in the case the offer is accepted (4). Once offerdetails are received from the buyer, a B2B transaction is activated andcompleted between the parties (5). At the end of the transaction, the sellercan require the buyer to remove the Offer from the bulletin board (6).


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-brokerreverse 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 isofficially acknowledged to the seller (4), who can activate a B2Btransaction with the Buyer (5).

Please note that, in this case, the seller role could be played, not only by asingle company/organization, but also, a seller could include multiplebuyers (for example, a group of SMEs) that club together to negotiate, forexample, large discounts. E-broker could be interfaced in this case byother online intermediary entities which operate other eMarketPlaces, forexample, intermediaries which aggregate homogeneously only a group ofbuyers or sellers in a given area.

Buyer

1. Post anOffer on theBulletingBoard 3. Browse and/or

trig open offersand Bid specificoffers

E-broker

Auctions:BullettinBoard

Seller5. B2B Transaction

Open Offers..............................................................................................................

6. Removean Offer

4. ReceiveOffer Details

2. Req. for Bid


Figure 79. The reverse auction information flow

Figure 80 shows the typical information flow of the last auction modalitysupported by E-broker: regular auctions. This modality is similar to theprevious one, with seller and buyer roles interchanged. In this case,sellers (labeled Seller in the figure) post offers to the E-broker auctionservice (1), which organizes auctions on these offers by temporary invitinginterested buyers (labeled Buyer in the figure) to formulate bids (2).Buyers post bids on the offer, and once a bid is accepted, this is officiallyacknowledged to the buyer (4), who can activate a B2B transaction withthe seller (5).

Buyer

1. Post arequest topurchase

3. Bid specificrequests

E-broker

ReverseAuctions


Requests ofPurchase

......................

......................

......................

......................

......................

4. BidAccepted

2. Req. for Bid


Figure 80. The regular auction information flow

A simplified aggregation model

As we have said, E-broker is intended to operate as a pure andindependent intermediary and not, from the functionality point of view, toprivilege the buyer-side or the seller-side. Thus, pure Selling or Buyingaggregations (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 tradedwithin the eMarketPlace. The catalogue will be made available in acentralized location, and it will be provided cross-references betweenbuyers and sellers interested in particular goods or/and services andbetween the general catalogue and the specific trader catalogue stored inthe Party Profile.

Additionally, E-broker supplies a set of services for managing thecentralized catalogue and navigating through the cross-references.Parties will be able to activate specific business transactions, for example,

Buyer

3. Bid specificOffers

E-broker

RegularAuctions

Seller 5. B2B Transaction

Offers..............................................................................................................

4. BidAccepted

2. Req. for Bid

1. Post Offers


to send an RFQ to all sellers, for a specific good and/or service, by directlyinterfacing the IT E-broker infrastructure. As usual, this service willsupplied on the basis of Trading Partner Agreements that parties willsubscribe with E-broker.

Figure 81 shows one of the possible aggregation services supplied byE-broker. In this case, a buyer (labeled Buyer in the figure) sends amultiple Request For Quote (RFQ) to the aggregation service of E-brokerfor 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 thebuyer (4) who, finally, can activate a B2B transaction with the seller (5).The E-broker’s value-added, in this case, lies in the ability to appropriatelyaggregate sellers’ catalogues, and to recognize and qualify, for a givenRFQ, the sellers that are able to supply the requested goods and/orservices.

Figure 81. The multiple Request For Quotation aggregation service

Buyer

3. Quotaionresponse

E-broker

AggregationService


4. Quotaionresponses

2. Req. for RFQ

1. Browse thecentralized catalogueand send RFQ


7.3.2 Considerations on the impact of XML on the architectureThere are several roles XML and related technologies can play inimplementing the E-broker application. It is clear that most of these tasks canbe designed and implemented using different techniques and tools.Nevertheless, our main aim in doing this case study has not been to showhow to design an e-business application in general, but to verify if XML andits 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 eachmain architectural component, the advantages and the disadvantages ofusing XML based technology. We will focus on a variety of areas where XMLcan be used, and show how these areas affect the E-broker system.

XML as a data representation and exchange formatAs a source data format for information about companies, products, servicesand Trading Partner Agreements (contracts), XML has several advantages.First of all, as a structured data format, it allows flexible and efficient datadescription. Since meta information about the data is also stored (both indocuments and DTDs), it is possible to interpret and validate dataautomatically, without any other information. This is a basic requirement forbuilding the E-broker. XML also allows the management of smaller pieces ofdocuments, and the creation of compound documents based on several otherdocuments. For example, the aggregation service would require a feature likethis. It would also benefit from the fact that XML documents arewell-structured, the data is stored in a hierarchical structure.

Probably, the most important role that XML can play in the E-brokerapplication concerns the usage of standardized XML-based data exchangeformats between trading partners, and between traders and E-broker. Torealize Trading Partner Agreements in the application we can effectively usethe Trading Partner Agreements Markup Language (tpaML). See Section6.2.1, “Trading Partner Agreements” on page 185).

There are also proposals for describing company and user profile informationaccording to various purposes, including identification, security, andpersonalization. These areas can be implemented using XML, but traditional,database oriented methods probably would reach the required level offunctionality with less complexity. However, these information needs to beexchanged between companies and the E-broker. For this purpose, XML, asan application-independent data format, could provide good solutions.


For example, the Platform for Privacy Preferences Project (P3P) developedby W3C, provides a general framework for informed online interactions. Thegoal of P3P is to enable users to exercise preferences over Web sites'privacy practices. P3P applications will allow users to be informed about Website 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 newproposal by several industrial companies (and IBM) for representing directoryservice information (that is store, for example, in LDAP servers) in XMLformat. DSML would provide this directory information to XML-basedapplications in their native environment and data format. This would allow forthe E-broker applications to retrieve company, product, service and customerdata over the Internet described in a standard format, DSML.

As another example, the Customer Profile Exchange (CPEX) initiative is anindustry organization dedicated to “developing an open standard to facilitatethe exchange of privacy-enabled customer information across enterpriseapplications. The CPEX standard integrates online and offline customer datain an XML-based data model for use within various enterprise applicationsboth on and off the Web”.

XML as a metadata standardMetadata, or data about data, provides information about data objects. Thisinformation can be used to label, catalog, locate and understand data, forexample, goods and services. Using metadata the productivity of the datamanagement 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 mainexamples of application domain independent metadata specifications. Bothstandards are developed by the W3C, primary for Web use.

E-broker traders can describe their products and services in an XMLlanguage for metadata description. This language can be especially designedfor this purpose. On one hand, this facilitates the interchange of this kind ofdata between traders and the E-broker, allowing automatic data incorporationindependently from the particular company’s information system. On theother hand, it allows a very flexible and homogenous categorization ofproduct and services.


A business example is the Product Information Exchange (PIX) protocol setthat support catalog interoperability on the Internet through definedguidelines for content, communication, format and presentation of productdata. PIX is under development by CommerceNet members(www.commerce.net).

Metadata information can also be used to describe queries. The user whowants to retrieve information about a particular service or good can specifycertain parts of a query document based on the metadata definition used bythe E-broker. The E-broker search engine can match this query document toits stored product and service descriptions. XML query languages are stillimmature, but there are already candidates that can be used in a workingsystem (see Section 1.2.11, “XML query languages” on page 25).

XML-based data processingXML tools allow the creation, modification, and handling of XML documentsautomatically. Standard programming interfaces, like the Document ObjectModel (DOM), or the Simple API for XML (SAX) provide programmableaccess to XML documents from applications (see Section 1.2.12, “ProcessingXML documents” on page 25 for more details about these technologies, andSection 3.2, “IBM XML development tools and utilities” on page 63 about IBMproducts and tools). XML extensions in data management applications, likethe XML Extender for DB2, provide XML-based interfaces to legacy and XMLdata (see Section 3.4, “XML extensions to IBM products” on page 89). Thisallows you to develop custom applications that operate on XML data (evenusing legacy sources).

The hierarchical nature of XML documents allows dynamic composition anddecomposition. Parts of XML documents can be identified, addressed,extracted, and combined with parts of other documents runtime, according tothe actual set-up and required information. This allows the building ofcomplex data from small data fragments. This feature is useful for creatingcatalogs, complex product and service descriptions, and to combine servicesand products together.

The heart of the E-broker architecture is the Advance B2B Directory Servicewhich includes information concerning traders, goods and servicescatalogues as well as party trading rules. This information is mostly in textformat, and it needs to be efficiently accessed in different ways for differentpurposes. Some of this data could be arranged into database structures, butit is hard to pre-define all kinds of tables for describing all kinds of informationpresent in these documents. XML provides efficient tools for organizing andhandling 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


and access the information. Document type definitions can help in automaticcategorization of documents, and queries and indexing can be built based onthis information.

XML also allows more complex queries than conventional databasetechnology. XML query standards and tools are still in development phase,but it is expected that they could bring powerful solutions to the E-brokerarchitecture.

XML translators can transform documents between different XMLvocabularies. This allows automatic conversions between business documentmodels used by different traders and the E-broker. The XSLT specificationdescribes how to transform one XML document into another, and an XMLvocabulary specifies formatting semantics. Tools based upon this technologycan automate tasks during the acquisition of business data from companies.

XML and presentationXML as a Web technology has strong support for presentation. TheExtensible Style Language (XSL) is a specification for applying formatting toXML documents in a standard way. It is primary designed for Web use, andalso has document manipulation capabilities beyond styling. Using XSL andXSLT (that describes the transformation of XML documents) different kinds ofpresentation formats can be used to deliver XML documents to the users.XML transcoding techniques help in transforming documents into the requiredformat. There are a wide variety of available formats, and new output formatscan also be described and used. Typical formats are paper-based, PDF andHTML. The transformation can be done automatically according totransformation rules. The best transformation format can also be selectedbased on the capabilities of the output device.

WebSphere Transcoding is a typical product solution to this task. It allows themodification of Web data, such as HTML pages, GIF or JPEG images, andXML documents. It uses standards-based technologies for the datatransformation, including Java, XML, XSL, Wireless Application Protocol(WAP), and Wireless Markup Language (WML). The initial contenttransformation mechanisms can be extended by IBM, independent softwarevendors (ISVs), or customers using plug-ins.

E-broker can effectively utilize this technology within the eMarketPlaceinformation portal layer and in the customer support service to providecontent in the right format according to their output devices, like personalcomputers or mobile phones.


XML and personalizationPersonalization is a critical feature of e-business application. It means theautomatic modification of presentation and content according to a user’sprofile. Usually, this applies to individual users, but companies would alsobenefit from this kind of service.

On one hand, using personalization services a trader could tailor the contentavailable for the E-broker. It can select typical trading partners, and receiveonly required information, monitor these selected company services,changes, and so on. On the other hand, traders could specify data formatsthey like to receive form E-broker. This means the selection of XMLvocabularies, and level of details they would like to receive from E-broker. Forhuman browsing, it would be also necessary to describe presentationpreferences based on the capabilities of presentation device and user’ssettings.

7.3.3 A building block architectureFrom a functional point of view, E-broker consists of a set of integratedcomponents arranged within three main functional layers: the basic ITinfrastructure layer (network components, security, policy accesses rules,and so on); the B2C service layer (delivering of specific and personalizedmarket and community news and analysis, customer support services, and soon); and the B2B service layer, which handles the specific brokerageactivities (B2B Directory and catalogue manager, auction manager, and soon). The first layer could be considered roughly durable in time, unlike thesecond and third layers, which are architected in a flexible way for acceptingnew services according to a plug-and-play modality.

E-broker basic infrastructure will be connected to the parties through asecure Internet connection. Figure 82 shows the two E-broker functionallayers giving also prominence to the main components constituting eachlayer. The figure depicts also the entities that have access to the E-brokereMarketPlaces: traders (buyers and sellers) and E-broker partners (banks,logistic companies, and so an) that can supply value-added services to thetrading community.


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 ITinfrastructure. Basic infrastructure layer components are the following:

• Security

The security component supplies a set of standard level functionalitywhich protect E-broker infrastructure from unauthorized accesses comingfrom Internet. It should handle a set of security issues such as, the firewallprotocol, intrusion protection, access control.

• Access Manager

This component manage the Community Trader accesses to E-Broker. Itsupplies the services to manage the traders access policy and their onlineregistration process as well as the trader profile.

Basicinfrastructurelayer

B2B onlineservice layer

Security

AccessManager

B2B IntegrationMiddleware

ContractsManager

B2B DirectoryService

AuctionsService

AggregationService

Customer SupportServices

Internet

CommunityTraders

E-broker

B2C servicelayer

eMarketPlaceInformation Portal

E-brokerPartners


• B2B integration middleware

This is the runtime B2B integration middleware that will supply thefront-end door for accessing and interacting traders IT with the E-brokerservices. This middleware will based on BPF/TPA.

B2C Basic service layer

This layer includes all those components that handle the specific brokerageactivities.

• eMarketPlace Information Portal

The eMarketPlace Information Portal delivers specific market andcommunity news and analysis, general and personalized information, andso on to the trader community.

• Customer Support Services

This component aims to supply the necessary functionality to support andfacilitate through the Web the community traders in accessing to theeMarketPlace. E-broker will play an active role in the eMarketPlace givingnot only technical support to the community members (for example,through help desk or call center facilities), but also it will deliver specificMarket news and information.

B2B Basic service layer

This layer includes all those components that handle the specific brokerageactivities.

• B2B Directory Service

This component handles the B2B advanced directory service businessmodel.

• 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 standardcontract repository.

The following section provides a set of Patterns for e-business that can beused to model the E-broker architecture.


7.3.4 E-broker application functional decompositionThis section analyzes the E-broker functionality by using the Pattern fore-business modelling approach introduced in Chapter 4, “Patterns for B2Cand B2B applications” on page 107. In particular, we will follow a bottom-upapproach in analyzing E-broker functionality. First, we will identify the logicalPatterns for e-business (application topologies) for all basic E-brokerapplication services (E-broker access and directory service, auction service,aggregation service, customer support services and so on) and customizingthese Patterns by obtaining a specific functional application decomposition.Thus, we will merge all basic customized application topology patterns into ageneral application topology which encompasses the whole E-brokerapplication. Finally, we will provide the runtime topology of the wholeE-broker application.

The following are the application topologies for all E-broker basic applicationservices.

E-broker access and directory service

This service can be modelled through the B2C Web-up topology 1. Thearchitecture provides, in this case, a Web Client which is used to build thefront-end application that supplies E-broker online subscribing facility,directory browsing and remote TPA authoring tools. The Web Clientinteracts with an application module that implements the Directory Servicebusiness logic on the second tier. This last tier accesses, among otherthings, to the Parties Profile database on which are maintained mostly ofthe application data. Figure 83 shows the application topology diagram forthe E-broker access and directory service.


Figure 83. Directory service: application topology

Auction service

Figure 84 shows the application topology diagram for the E-broker auctionservice. The auction service is based on the Jointly Managed three-tierB2B pattern. Traders interact with the E-broker by using executablecontracts which encode all business integration services related to theauction processes. There are three kind of contracts that model theinteraction process between trader (buyer and seller) IT infrastructuresand the E-broker; one for each type of auction modality, although in thefigure, just a generic Auction Contract is shown. Contracts describe a setof 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 isconnected with a back-end application that manages all auction services.Connections between tiers can be synchronous or asynchronous.

Web ClientDirectoryService

async/sync

Client E-broker tier


Figure 84. Auction service: application topology

Multiple RFQ aggregation service

Figure 85 shows the application topology diagram for the E-broker multipleRFQ aggregation service. This service has been modelled by using acombination of two B2B patterns: the Business Protocol Managed and theJointly Managed. The first pattern is used to model the buyer/E-brokerinteraction (Partner A in the figure) and the second to model theseller/E-broker interaction (Partner B in the figure). Also in this casebetween E-broker and Traders holds an electronic contract which encodesall business integration services related to the aggregation processes. TheE-broker aggregation service is arranged on an intermediary tier which isconnected with a back-end application that manages the aggregation

Trader A

AuctionServices

AuctionExecutable

Contract

E-broker tier

Trader App AuctionExecutable

Contract

Trader B

AuctionServices

Auctionmanager

AuctionServices

N:Masync

mutually agreedmsgs

1:Nsync

N:1sync

AuctionServices

AuctionExecutable

Contract

Trader App

AuctionExecutable

Contract


application. Connections between tiers can be synchronous orasynchronous.

Figure 85. Aggregation service: application topology

eMarketPlace Information Portal and the Customer Support service

The eMarketPlace Information Portal and the Customer support serviceare a set of components that facilitate the trading community to access theE-broker services through the Web. E-broker plays an active role in theeMarketPlace giving not only technical support to the community members(for example, through help desk or call center facilities), but also it deliversto the Traders personalized market news and information. Thearchitecture provides, in this case, a Web Client which is used to build thefront-end application for accessing to all customer support services. TheWeb Client interacts with an application module that implements thecustomer support services business logic on the second tier. This last tieraccesses, among other things to various databases on which aremaintained the application data. Figure 86 shows the application topologydiagram for the customer support services.

Partner A E-broker tier

N:Masync server-specified

msgs / sync

Post anRFQ

AggregationExecutable

Contract

1:NsyncBuyer

App N:1async

mutually agreedmsgs

Aggregationmanager

N:Masync

mutually agreedmsgs

SellerApp

AggregationServices

1:Nsync


Contract

1:Nsync

N:1sync

Partner B


Contract


Figure 86. Customer support service: application topology

Figure 87 shows the general application topology of E-broker. All applicationtopologies of the various E-broker services previously proposed have beenmerged to form the E-broker application topology.

Web ClientCustomerSupportServices

async/sync

Client E-broker tier

eMarketPlaceInformation

Portal


Figure 87. The application topology of E-broker

Figure 88 shows the runtime topology of E-broker.

Trader

AuctionServices

AuctionExecutable

Contract

E-broker tier

Trader App

Auctionmanager

AuctionServices

N:Masync

mutually agreedmsgs

1:Nsync

N:1sync


Contract

Aggregationmanager

CustomerSupportServices


Contract

AggregationServices

AggregationServices

Web Client

eMarketPlaceInformation

Portal

DirectoryService

AuctionExecutableContract


Figure 88. Runtime topology of E-broker

Table 19 provides the product mapping between the E-broker runtimetopology nodes depicted in Figure 88 above. We found in the IBM catalogueall necessary products fitting the E-broker IT infrastructure. Evidently, insome cases, when a standard product is not available or it does not cover theapplication requirements, a specific developing process is assumed.

Table 19. Product mappings for the E-broker runtime topology

Nodes Products

B2B middleware manager WebSphere B2B integratorSpecific Development

B2B Directory Service DB2 UDB/XML ExtenderSpecific Development

E-Broker

INTERNET

Demilitarized Zone (DMZ)

Pro

toco

lFire

wal

l

Webapplication

server

Dom

ain

Fire

wal

l

Directoryand

SecurityServices

internal network Demilitarized Zone (DMZ)

Trader

Webapplication

serverB2B

middlewaremanger

Pro

toco

lFire

wal

l


Domain nameserver

WebClient

Dom

ain

Fire

wal

l

Auction &Aggregation

managerand data

internal network

B2B Directory Service

Back-endCustomer

Support andeMIP App

Directoryand

SecurityServices

B2Bmiddleware

mangerWeb

applicationserver

Auction &Aggregation

managerand data


and data


7.4 Initial E-broker design activities

The design and implementation of the E-broker project is well beyond thepurpose of this book — it requires several months of work by applicationdomain and IT experts to be finished! In this section, we propose some initialdesign activities, mainly concerned with the adoption of XML in modelling thevarious E-broker services, that we believe are in line with the aims of thisbook: to show in practical terms possible usages of XML in developing B2Cor and B2B applications.

As we have said, the usage of XML is pervasive in designing an e-businessapplication; thus, selecting which part of the project to design has beendifficult. Incidentally, we decided to show you the usage of XML under twodifferent, but also interrelated aspects: to write the E-broker access TPAcontracts that trading partners can use to access to the E-broker services,and to project the data structure needed to implement the directory service.

Domain name server Non-applicable

eMarketPlace Information Portal (eMIP) IBM Enterprise Information PortalLotus NotesSpecific Development

Customer Support Service Tivoli Service Desk

B2B Services Specific Development

Directory and security services SecureWay Directory

Protocol firewall and domain firewall secureWay FirewalleNetworkFirewall 3.2

User Web Browser

Web application server IBM HTTP ServerWebSphere Application Server AdvancedEdition including among other things:- XML Enabler- Apache Cocoon- WebSphere Transcoding Publisher

Nodes Products


7.4.1 E-broker access service TPAsThis section proposes some TPA models defining business transactionsbetween Traders and E-broker — four basic TPA templates corresponding tothe 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 detailsconcerning other TPA layers.

Bulletin board auction

E-broker services with the Seller acting as a clientActions

Action 1.Request Name: postOfferRequest Message: postOfferMessageEnable: removeOffer

Action 2.Request Name: removeOfferRequest Message: removeOfferMessageResponse Name: confirmOfferDeletionResponse Message: confirmOfferDeletionMessage

Start Enabled ActionsRequestName: postOffer

E-broker services with the Buyer acting as a clientActions

Action 1.Request Name: postABidRequest Message: postAMessageResponse Name: offerrDetailsResponse Message: offerrDetailsMessage

Action 2.Request Name: requestNewOffersRequest Message: requestNewOffersMessageResponse Name: newOffersResponse Message: newOffersMessage

Start Enabled ActionsRequestName: requestNewOffers

Buyer services with the E-broker acting as a clientActions

Action 1.


Request Name: requestForABidRequest Message: requestForBidAMessage

Start Enabled ActionsRequestName: requestForBid

Seller services with the Buyer acting as a clientActions

Action 1.Request Name: purchaseOrderRequest Message: purchaseOrderMessage

Regular auction

E-broker services with the Seller acting as a clientActions

Action 1.Request Name: postOfferRequest Message: postOfferMessage


Action 1.Request Name: postABidRequest Message: postAMessageResponse Name: offerrDetailsResponse Message: offerrDetailsMessage

Buyer services with the E-broker acting as a clientActions

Action 1.Request Name: requestForABidRequest Message: requestForBidAMessage



Reverse auction


Action 1.Request Name: postRequestOfPurchaseRequest Message: postRequestOfPurchaseMessage

E-broker services with the Seller acting as a client


ActionsAction 1.

Request Name: postABidRequest Message: postAMessageResponse Name: requestOfPurchaseDetailsResponse Message: requestOfPurchaseDetailsMessage

Seller services with the E-broker acting as a clientActions

Action 1.Request Name: requestForABidRequest Message: requestForBidAMessage

Buyer services with the Seller acting as a clientActions


Aggregation Service


Action 1.Request Name: postAMultipleRFQRequest Message: postAMultipleRFQMessageResponse Name: QuotationsDetailsResponse Message: QuotationsDetailsMessage

Seller services with the E-broker acting as a clientActions

Action 1.Request Name: RFQRequest Message: RFQMessageResponse Name: QuotationDetailsResponse Message: QuotationDetailsMessage



7.4.2 The directory service data model in DB2 XML ExtenderThe E-broker B2B directory service in principle is very similar to a well-knownYellow Pages service. By using this service, buyers and sellers have the


chance to promote themselves in the eMarketPlace and, at the same time, toexpose the list of services and the types of contracts that they accept.

The E-broker directory service stores information about companies. Thisinformation includes general data (name, address, contact persons, Webaddress, and so on), and TPAs accepted by that company. For storing TPAs,we used the standard Document Type Definition for TPA (tpa.dtd). We alsodeveloped a sample DTD for storing general company-related information(com_info.dtd), and business-related information (com_biz.dtd). The finalcompany 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 company’s 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;


Company data can be described in XML format using these DTDs. Thefollowing 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">[email protected]</EMail><EMail Type="secondary">[email protected]</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">[email protected]</EMail>

</InternetLocation></CompanyInfo><BusinessProfile><TPASubparts><TPA>...</TPA>

</TPASubparts><TPACollection><TPA>...</TPA><TPA>...</TPA>

</TPACollection></BusinessProfile>

</Company>


To store XML files in DB2 Universal Database, we utilize the XML Extenderinterface. We developed a simple database model that reflects theinformation described in these DTDs. This model is the EB_DB database(Figure 89).

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. Thisinformation is defined by the com_info.dtd. This table contains data in adatabase-centered way that helps in using this information for non-XMLapplications. The tpa_tab table contains complete TPA documents (XMLdocuments), while the tpa_side_tab contains some elements from TPAdocuments.

To establish the mapping between the XML data and database entries, wespecified document access definition (DAD) files. There are two differentways of storing XML data in DB2 using the XML Extender: we can storecomplete XML files, or we can associate database elements with XML data.

Basic information about a company could also be useful for otherapplications, therefore we store this data in database columns in thecompany_tab table, and compose the XML files from these tables. This iscalled an XML collection. XML collections are useful when the data isaccessed both using XML and database techniques, and it is stored inseveral database tables.

company_tab tpa_tab tpa_side_tab

company information TPA information

nameaddresscontact persons. . .

complete TPAs TPA elements

E-broker database: EB_DB


TPAs, on the other hand, are used as entities, and can be stored intact inDB2 tables. This is the XML column storage method. XML columns work wellfor archiving XML documents. Elements and attributes of these XMLdocuments can also be mapped to database tables (so called side tables) tohelp indexing and structural search. We defined a tpa_side_tab table for thispurpose.

To set up the DB2 XML Extender, we followed the steps described in the DB2XML 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 relationbetween XML documents based on com_info.dtd and database tablecompany_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 thetpa_side_tab table.


<?xml version="1.0"?><!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 eMarketPlaceintermediation field and outlined a new project case study, called E-broker, inthis particular domain. We selected the B2B eMarketPlace intermediationfield 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 anddiscuss from both the project and the design point of view, as well as whataffects the role that XML plays in these types of systems. In particular, thistype of application helps you understand in practical terms many moreelements in applying XML than simply analyzing a traditional B2B or B2Capplication example. B2B eMarketPlace intermediaries are strongly emergingin the B2B market to complement and empower the traditional B2B modelcentered around the buyer-seller transaction paradigm. B2B eMarketPlaceintermediaries mediate among buyers and sellers by facilitating the businesstransaction process and, in some cases, by supplying value-added function tothe business transaction chain.

The chapter ends with the description of some design activities of theE-broker project.


Appendix A. An example of a OBI TPA XML document

This appendix proposes the full OBI TPA XML document between the LargeCo and Pens We Are companies, as generated by the IBM XML VisualBuilder tool. It was developed in Section 6.2.4, “Using the IBM Visual XMLBuilder for a specific OBI TPA” on page 216 .

A.1 The OBI TPA between Large Co and Pens We Are

<?xml version="1.0"?><!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>


<AddressLine>1 Main Street

</AddressLine><City>

SmallTown</City><State>

NY</State><Zip>

10000</Zip><Country>

USA</Country>

</Address><Address>

<AddressType>billing



Accounting Department</AddressLine><AddressLine>

100 Bean Counters Road</AddressLine><City>

Any City</City><State>

CT</State><Zip>


USA</Country>

</Address><Address>

<AddressType>shipping




Procurement Department</AddressLine><AddressLine>

99 Purchase Road</AddressLine><City>

Buy City</City><State>

NY</State><Zip>


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><ContactTelephone Type="primary">

914-111-6790</ContactTelephone><EMail Type="primary">

[email protected]</EMail><Fax>

914-111-6780</Fax>

</Contact>

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

<Contact Type="primary"><LastName>

Blow</LastName><FirstName>

Joe</FirstName><MiddleName>

J.</MiddleName><Title>

Buyer</Title><ContactTelephone Type="primary">



914-111-6780</Fax>

</Contact></Member><Member MemberId="MemberId18" IdCodeType="ZZ">

<PartyName Partyname="PensWeAre">



<AddressType>location


Pens Are We</AddressLine><AddressLine>

Building 001</AddressLine><AddressLine>

123 High Street</AddressLine><City>

EarthQuake City</City>


<State>CA

</State><Zip>


USA</Country>


<LastName>Doe


Jane</FirstName><MiddleName>

E.</MiddleName><Title>

Vice President of Internet Sales</Title><ContactTelephone Type="primary">



945-123-9999</Fax>

</Contact></Member><Arbitrator MemberId="attr3" IdCodeType="attr4">

<PartyName Partyname="XYZArbitrator">



<AddressType>XYZArbitrator


Suite 3


</AddressLine><AddressLine>

77 Lawyers Blvd</AddressLine><City>

ABC City</City><State>

MA</State><Zip>


USA</Country>


<LastName>Black


Joe</FirstName><MiddleName>

K.</MiddleName><Title></Title><ContactTelephone Type="primary">



780-333-5000</Fax>

</Contact></Arbitrator>

</Participants><Duration>

<Start><Date>

April 6, 2000</Date><Time>


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">

https://www.pensarewe.com/coyote/servlet/OBIsell</URL><URL URLName="responseURL">


https://www.pensarewe.com/coyote/servlet/OBIsell</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 Partyname="LargeCo">

</OrgName><IssuerOrgName>

VeriSign, Inc.</IssuerOrgName><IssuerCertSource>

http://www.verisign.com/certs</IssuerCertSource>

</Party><Party>



GTE, Inc.</IssuerOrgName><IssuerCertSource>

http://www.gte.com/certs</IssuerCertSource>

</Party></Certificate>


</Encryption><Authentication>

<CertificateAuthen><Protocol>

SSL</Protocol><Version>

3.0</Version><Certificate>

<CertType>X509.V3




</OrgName><OrgCertSource>

http://www.verisign.com/certs</OrgCertSource><IssuerOrgName>



</Party><Party>


</OrgName><OrgCertSource>

http://www.gte.com/certs</OrgCertSource><IssuerOrgName>




</CertificateAuthen></Authentication>


</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







</Party><Party>







</NonRepudiation></MessageSecurity>

</DocExchange><BusinessProtocol>

<ServiceInterface InterfaceId="attr6"><OrgName Partyname="LargeCo">

</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>


<Presume>fail

</Presume></ServerServiceTime><StartEnabled>

<RequestName>putOPOR

</RequestName></StartEnabled>

</ServiceInterface><ServiceInterface InterfaceId="attr17">


</OrgName><Client>


</OrgName></Client><ActionMenu>

<Action ActionId="attr18" Type="basic"Invocation="asyncOnly">

<Request><RequestName>

shop</RequestName><RequestMessage>

shopMessage</RequestMessage>

</Request></Action><Action ActionId="attr19" Type="basic"

Invocation="asyncOnly"><Request>

<RequestName>putOPO

</RequestName><RequestMessage>

OBIPO</RequestMessage>

</Request></Action>

</ActionMenu><ServerServiceTime>

<ServiceTime>3600

</ServiceTime>


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 onusing 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 theInternet 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 withthe redbook form number.

B.2 Using the Web material

The additional Web material that accompanies this redbook includes thefollowing:

File name DescriptionSG246104.zip 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


ftp://www.redbooks.ibm.com/redbooks/



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 companiesproposed in chapter 6

OBITPA.dtd.xmi XML model of the OBI TPA between Large Co and Pens WeAre 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 ofthe Web material into this folder.


Appendix C. Special notices

This publication is intended to help technical professionals who are involvedin the design of B2B and B2C applications using XML.The information in thispublication is not intended as the specification of any programming interfacesthat are discussed in this document. See the PUBLICATIONS section of theIBM Programming Announcement for any IBM products mentioned in thisdocument for more information about what publications are considered to beproduct documentation.

References in this publication to IBM products, programs or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only IBM's product, program, or service may beused. Any functionally equivalent program that does not infringe any of IBM'sintellectual property rights may be used instead of the IBM product, programor service.

Information in this book was developed in conjunction with use of theequipment specified, and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, North Castle Drive, Armonk, NY10504-1785.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information between independentlycreated programs and other programs (including this one) and (ii) the mutualuse of the information which has been exchanged, should contact IBMCorporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The use of this information or theimplementation of any of these techniques is a customer responsibility anddepends on the customer's ability to evaluate and integrate them into thecustomer's operational environment. While each item may have beenreviewed by IBM for accuracy in a specific situation, there is no guaranteethat the same or similar results will be obtained elsewhere. Customers


attempting to adapt these techniques to their own environments do so at theirown risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

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, PlanetTivoli, and Tivoli Enterprise are trademarks or registered trademarks of TivoliSystems Inc., an IBM company, in the United States, other countries, or both.In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - TivoliA/S.

400 Manage, Anything, AnywhereAIX MQSeriesAlphaWorks Net.DataAS/400 NetfinityAT NetViewCICS NotesCross-SIte OS/2CT OS/390Current QuickplaceDB2 RS/6000DB2 Extenders S/390DB2 OLAP Server SecureWayDB2 Universal Database SmartSuiteDirectDOM SPDomino System/390EDMSuite TeamConnectionIBM � TivoliIBM Global Network Tivoli CertifiedImagePlus Tivoli ReadyIntelligent Miner TMEKnowledgeX Visual WarehouseLearning Space VisualAgeLotus VisualInfoLotus Notes WebSphereLotus SmartSuite Wizard

Redbooks Redbooks Logo


C-bus is a trademark of Corollary, Inc. in the United States and/or othercountries.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States and/or other countries.

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countrieslicensed exclusively through The Open Group.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarksowned by SET Secure Electronic Transaction LLC.

Other company, product, and service names may be trademarks or servicemarks of others.

Appendix C. Special notices 299

Appendix D. Related publications

The publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this redbook.

D.1 IBM Redbooks

For information on ordering these publications see “How to get IBMRedbooks” 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 2using 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 ApplicationServer, 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 CORBAEJB 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 Agefor Java, SG24-2144


D.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMsbutton at ibm.com/redbooks for information about all the CD-ROMs offered,updates and formats.

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/sgml-xml.html

•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

CD-ROM Title Collection KitNumber

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




•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.oasis-open.org/cover/sgml-xml.html

•http://www.research.ibm.com/journal/sj38-1.html

•http://www.alphaworks.ibm.com

•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

•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


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 fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the IBM Redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the Redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

IBM employees may register for information on workshops, residencies, and Redbooks by accessingthe 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 developedand written by the ITSO technical professionals; click the Additional Materials button. Employeesmay access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


http://www.elink.ibmlink.ibm.com/pbl/pbl



http://w3.itso.ibm.com/

http://w3.ibm.com/





mailto:[email protected]





IBM Redbooks fax order form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


Glossary

Application Service Provider (ASP) An ASP isan agent or broker that aggregates, facilitatesand brokers IT services to deliver IT-enabledbusiness solutions across a network viasubscription-based pricing.

attribute In XML, a name="value" pair that canbe placed in the start tag of an element. Thevalue must be quoted with single or doublequotes.

Cascading Style Sheet (CSS) CSS defines astylesheet language for HTML 4.0. CSS allowsa Web page designer to separately specify styleelements of a Web page, such as colors, fontsand font styles.

case-sensitive Indicates whether anapplication, processor, or operating systemdistinguishes between upper and lower case. Ifit does, it is case-sensitive. XML tags arecase-sensitive, but HTML tags are not.

Customer relationship management (CRM)CRM includes the systems and infrastructurerequired to analyze, capture and share all partsof the customer’s relationship with theenterprise. From a strategy perspective, itrepresents a process to measure and allocateorganizational resources to those activities thathave the greatest return and impact onprofitable customer relationships.

content model In XML, the expressionspecifying what elements and data are allowedwithin an element.

Document Object Model (DOM) This allowsthe representation and manipulation of an XMLdocument in memory as a programming object.DOM is defined by the World-Wide WebConsortium.

DOM (see Document Object Model).

DOM Tree A DOM Tree is an in-memoryrepresentation of an XML Document.

Document Type Definition (DTD) A DTD is adefinition of which Elements and Attributes areacceptable in a specific XML file. The DTD

© Copyright IBM Corp. 2000

therefore defines a subset of XML which may beused for a particular application.

EBNF Extended Backus-Naur Form. A formalset of production rules that comprise a grammardefining another language, such as XML.

Electronic data interchange The automaticmachine-to-machine transfer of tradingdocuments (e.g., invoices and purchase orders)using electronic networks such as the internet.Originally conducted only through value-addednetworks, EDI is gradually moving to theInternet.

element In XML, a start tag and its end tag, plusthe content between the tags. An empty tag isalso an element.

empty declaration In XML, the DTD declarationfor an empty tag. For example, if <foo/> is anempty tag, the empty declaration looks like:<!ELEMENT foo EMPTY>.

empty tag In XML, a start and end tagcombined in one tag. The tag has a trailingslash, so an XML parser can immediatelyrecognize it as an empty tag and not botherlooking for a matching end tag. For example, iffoo is an empty tag, it looks like <foo/>.

entity In XML, an entity declaration provides theability to have constants or replacement strings,which are expanded by a pre-processor. Anentity declaration maps some token to areplacement string. Later the token can beprefixed with the & character and thereplacement string is put in its place.

Enterprise JavaBeans (EJB) The EnterpriseJavaBeans specification defines a way ofbuilding transactionally aware business objectsin Java.

Java Server Page (JSP) Java Server Pagesare Web pages that include dynamic tags whichare executed on the server. JSPs are thepresentation layer for Web-based applicationsbuilt in Java.

307

Servlets Servlets are Java objects which executeon 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 processof optimizing delivery of goods, services andinformation from supplier to customer. SCM is aset of business processes that incorporate atrading-partner community engaged in a commongoal of satisfying the end customer.DTD.

Trading Communities Trading communitiesbring together buyers and sellers in a centralonline location to trade, using various onlinemechanisms including auctions and exchanges,in addition to industry content and applicationservices. Trading communities are owned andoperated by both large industry players in closedtrading networks and by neutral parties in morefragmented open communities.

URI/URL A Uniform Resource Identifier (URI)and Uniform Resource Locator (URL) uniquelydefines a location on the Web. URLs are familiarto anyone who browses the Web (for examplehttp://www.ibm.com), and the term URI is amore general term which also incorporates otherschemes for identifying resources.

valid An XML document is valid if its contentconforms to the rules in its DTD.

WAP Wireless Application Protocol. Offersinternet browsing from wireless handsets

Web Application A WebSphere Web applicationis a collection of static pages, JSPs and Servletsthat share a common URL prefix, and togethermake a complete application.

well-formed An XML document is well-formed ifthere is one root element, and all its childelements are properly nested within each other.Start tags must have end tags, and each emptytag must be designated as such with a trailingslash. Also, all attributes must be quoted, and allentities must be declared.

white-space In XML, characters that are notvisible, but used in formatting documents orprograms. These characters include the SPACE,

TAB, NEWLINE, and CARRIAGE-RETURNcharacters.

XSL Stylesheet The eXtensible StylesheetLanguage defines stylesheets for XMLDocuments. It is composed of two parts: theformatting objects, and XSLT (see below). XSL isdefined by the WorldWide Web Consortium.

XSLT eXtensible Stylesheet LanguageTransformations This defines the part of theXSL specification which allows the stylesheet toreformat and reorganize the XML data. It is mostoften used to transform XML into XSL.


http://www.ibm.com

Index

AAggregation 245Application Framework for e-business 179Application Service Providers 246Auctions 245

BB2B online intermediary 239B2B server 190B2B XML framework 177B2C 139B2C application model 140Back end servers 141BizTalk 30, 183BPF 177, 204BPF components 208business integration 177Business-to-business Protocol Framework 177,184, 204, 208business-to-consumer 139Business-to-customer 139business-to-employee 145

CCC/PP 23, 160client pull 143Collaborative portal 146Commerce Extensible Markup Language 160Commerce XML (cXML) 182, 205CommerceNet 30Common Business Library 159Composite Capability/Preference Profiles 23, 160content generation 153Content management 148CORBA 179CPEX 156Customer Profile Exchange 156Customization 158cXML 160

DDB2 XML Extender 29developerWorks portal 165Directory Services Markup Language 155

© Copyright IBM Corp. 2000

Distributed Management Task Force 182Document Object Model 27Document Style Semantics and Specification Lan-guage 24Document Type Definition 21document type definition 18Document Type Definitions 21DOM 27, 28, 29DOM Level 2 28DOM Level1 28DSML 155DSSSL 24, 29DTD 18, 21, 22DTD repositories 22Dublin Core 22

EebXML project 182eCo Specification 183e-commerce 139, 157e-commerce portal 146electronic commerce 139Electronic Data Interchange 181electronic retail 139, 157eMarketPlace 239, 241eMarketPlace Information Portal 267eMarketPlaces 241Enterprise Java Beans 179, 212Enterprise portal 144enterprise portal 156Enterprise Portals 11, 110e-retail 139, 157Exchange 245Extensible HyperText Markup Language 23Extensible Markup Language 17Extensible Style Language 24, 260

FFront end servers 141

GGeneralized Markup Language 16GML 16

309

HHTML 16, 17, 19HTTP 16, 196Hypertext Markup Language 17HyTime 29

IIBM Content Manager 167IBM Enterprise Information Portal 166IBM Intellectual Property Network 164IBM Visual XML Builder 216IBM WebSphere B2B Integrat 177IBM XML Parser for Java 26IBM XML Tools 217ICE 159Information and Content Exchange 159Information portal 145International Standards Organization 29ISO 29

JJava API for XML Parsing 29JAXP 29

Kknowledge management 168Knowledge portal 145

LLotus Raven 168

Mmarkup language 18MathML 30Metadata 21, 156MQSeries 196

NNamespaces 30Net.Commerce 160, 172

OOASIS 30, 182, 185OBI 159OFX 159Open Applications Group 23, 183

Open Buying on the Internet 23, 159, 212Open Buying on the internet 205Open Buying on the Internet (OBI) 202Open Financial Exchange 159Open Trading Protocol 159Open Travel Alliance 23Organization for the Advancement of Structured In-formation Standards 30OTP 159

PP3P 159, 258PDA 160personal digital assistans 160Personalization 149, 152PICS 22PIX 158Platform for Internet Content Selection 22, 258Platform for Privacy Preferences Project 159, 258Product Information Exchange 158, 259Pyxie 29

QQuery reporting 156

RRDF 22, 158RDF Schema 22RDF Schemas 22Resource Description Framework 19, 22, 158RosettaNet 23, 159, 183

SSAX 26, 28SAX API 26search engine 19server push 143SGML 17, 29Simple API for XML 26SMTP 196Standard Generalized Markup Language 16

Ttag 18TPA 177tpaML 23, 184, 185, 190Trading Partner Agreement Markup Language 185


Trading Partner Agreement markup language 23Trading Partner Agreements 177, 184Transcoding 172transcoding 24

UUML 157UN/CEFACT 182Unicode 29Unified Modeling Language 157Uniform Resource Identifier 20Uniform Resource Locator 20Unit of Business 185unit of business 188URI 20URL 20User profile 154user profile 152User to Business 139

VVAN-EDI 197

WW3C 17, 19, 29W3C Mobile Access Activity 161W3C Technical Reports 20WAE 24, 160WAP 25, 160WAP Binary XML Content Format 24WAP Forum 160WBXML 24Web portal 143WebSphere 25, 171WebSphere B2B Integrator 184WebSphere Commerce Studio 172WebSphere Commerce Suite 160, 172WebSphere Studio 174WebSphere Transcoding 25WebSphere Transcoding Publisher 172WebSphere User Profile 173Wireless Application Environment 24, 160Wireless Application Protocol 160, 260Wireless Markup Language 24, 260Wireless Telephony Application Specification 24WML 24WMLScript 24

World Wide Web Consortium 17, 29

XxCBL 159Xerces 26XHTML 23, 161XLink 20, 150XLinks 162XMI 156, 158, 217XML 17, 18, 19, 30XML B2B framework 181XML DTD 162XML Enabler 163XML Fragments 162XML Linking Language 20XML Metadata Interchange 156, 158XML Namespaces 21, 22, 28XML parser 25XML Path Language 21XML Pointer Language 21XML Query Tools 150XML Schema 21XML.ORG 185XML.org 182XML/EDI 159XML/EDI Group 183XPath 21, 30, 150XPointer 21, 150XPointers 162XSL 24, 30, 150, 155, 162, 260XSL stylesheet 24XSL stylesheets 162XSL Transformations 24XSLT 24, 150, 155

311


IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where aRedbook "made the difference" in a task or problem you encountered. Using one of the followingmethods, please review the Redbook, addressing value, subject matter, structure, depth andquality 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 [email protected]

Document NumberRedbook Title

SG24-6104-00The XML Files: Using XML for Business-to-Business andBusiness-to-Consumer Applications

Review

What other subjects would youlike to see IBM Redbooksaddress?

Please rate your overallsatisfaction:

O Very Good O Good O Average O Poor

Please identify yourself asbelonging to one of thefollowing groups:

O Customer O Business Partner O Solution DeveloperO IBM, Lotus or Tivoli EmployeeO None of the above

Your email address:The data you provide here maybe used to provide you withinformation from IBM or ourbusiness partners about ourproducts, services or activities.

O Please do not use the information collected here for futuremarketing or promotional contacts or other communications beyondthe scope of this transaction.

Questions about IBM’s privacypolicy?

The following link explains how we protect your personal information.ibm.com/privacy/yourprivacy/




http://www.ibm.com/privacy/yourprivacy/


http://www.ibm.com/privacy/yourprivacy/

(0.5” spine)0.475”<->0.875”

250 <-> 459 pages

The XML Files: Using XM

L for B2B and B2C Applications

®

SG24-6104-00 ISBN 0738418102

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL 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


XML in IBM’s 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.

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.




The XML Files: - CiteSeerX

Documents

Transcript of The XML Files: - CiteSeerX