B2B Integration : A Practical Guide to Collaborative E-commerce

nioioimuc;./! 

1011 

1 

1 

.«.•.«! 

^,J/MiiW«S«| 

'01101100 M! 

-J 

Gunjan Samtani 

editors 

Marcus Hcaley 

Shyam Samtani 

'llOlOioilOIlOL 

JlOOO) 

fOllPOl 

B2B Integration 

A Practical Guide to 

Collaborative E-commerce 

Imperial College Press



Collaborative E-commerce

This page is intentionally left blank



Collaborative E-commerce 


Divisional Vice President 

Information Technology Group UBS PaineWebber 

editors 

Marcus Healey & Shyam Samtani 

Imperial College Press

Published by 

Imperial College Press 

57 Shelton Street 

Covent Garden 

London WC2H 9HE 

Distributed by 

World Scientific Publishing Co. Pte. Ltd. 

P O Box 128, Farrer Road, Singapore 912805 

USA office: Suite 202, 1060 Main Street, River Edge, NJ 07661 

UK office: 57 Shelton Street, Covent Garden, London WC2H 9HE 

British Library Cataloguing-in-Publication Data 

A catalogue record for this book is available from the British Library. 

B2B INTEGRATON: A PRACTICAL GUIDE TO COLLABORATIVE E-COMMERCE 

Copyright © 2002 by Imperial College Press 

All rights reserved. This book, or parts thereof, may not be reproduced in any form or by any means, 

electronic or mechanical, including photocopying, recording or any information storage and retrieval 

system now known or to be invented, without written permission from the Publisher. 

For photocopying of material in this volume, please pay a copying fee through the Copyright 

Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA. In this case permission to 

photocopy is not required from the publisher. 

ISBN 1-86094-323-3 

ISBN 1-86094-326-8 (pbk) 

This book is printed on acid-free paper. 

Printed in Singapore by UtoPrint

Dedications 

I would like to dedicate my work to my parents — Dr. Shyam Samtani 

and Kaushlya Samtani, my parents-in-law — the late Ashok Sadhwani 

and Neeta Sadhwani and my loving wife Dimple. Thank you for your 

prayers, encouragement, love and care, I could not have made it without 

you all. It is great to know I am where I belong. 

V


Acknowledgements 

The journey from mental conception to ultimate execution in black and 

white is arduous, hurdled with various set backs. At such moments, 

one's kith and kin inspire and encourage; colleagues cooperate and 

sometimes collaborate; friends motivate and lend helping hands. I am 

indeed fortunate enough to have such a galaxy of well wishers to whom 

I owe my gratitude. 

I express my sincere thanks to Mrs. Dimple Samtani, my spouse, 

who ran errands for me, gathering material, formatting the chapters, 

designing the graphics and showing remarkable patience while I was 

busy authoring the book. 

I owe my gratitude to my parents Dr. Shyam Samtani and Mrs. Kaushi 

Samtani, who came all the way from India to help and inspire me when 

I worked both ends of the clock. My dad, who is himself a professor of 

English Literature and has worked as an editor and author of several 

publications, was of immense help in language editing of the book. 

I thank Dr. Marcus Healey for his seasoned suggestions, experienced 

contribution and guidance that have gone into the shaping of this book. 

I thank Mr. Evan Schwartzman and Mr. Kenneth Tamburello, my 

dear colleagues, with whom I frequently discussed the lay out, contents 

of and approach to the book. They were ready with ideas and insightful 

comments when I was sometimes low. 

I can hardly overemphasize the role of Mr. Aran Sharma, Mr. Abhay 

Singh and Mr. Soumya Mawane whose invaluable graphics and images 

substantiate the points made by me in the book. I owe my thanks to all 

of them for their time and efforts. 

I am indebted to Ms. Geetha Nair of Imperial College Press and 

Mr. Loo King Boon of World Scientific for publishing this book. Without 

their cooperation the book could not have gone to print and thereby to 

the readers. 

vu


About the Author 

Gunjan Samtani is Divisional Vice President, Information Technology 

at UBS PaineWebber, one of the world's leading financial services 

firms. Prior to joining UBS PaineWebber, Gunjan was Associate Director, 

Global Information Technology, Bear Stearns and Company, the 4th 

largest U.S. brokerage and financial firm with more than $30 billion in 

assets. In this capacity, he was responsible in pioneering, managing and 

directing several critical, multi-million dollar business applications. Prior 

to Bear Stearns, Gunjan worked as a Senior Business Analyst with 

Amdahl (a Fujitsu Company), one of the largest companies of the world 

specializing in integrated computing solutions. At Amdahl, Gunjan was 

responsible for managing the design and delivery of multiple projects for 

financial industry. Before joining Amdahl, Gunjan was working as Senior 

Systems Analyst and Webmaster at New Jersey Technical Assistance 

Program. Gunjan has also worked as an interim CIO of India's first online 

investment portal EquityMaster.com and Personalfn.com. 

Gunjan brings together a very strong technical and business experience 

in various industries. He has several years of experience in the management, 

design, architecture, and implementation of large-scale EAI and 

B2B integration projects. Gunjan has an M.S. in Computer Science, M.S. 

in Management Information Systems and M.S. in Computational Finance 

from Carnegie Melon University (on-going). He has been involved in 

business and technical writing for several years and is the author of 

more than 100 articles and research publications in the field of finance 

and technology. He has also presented papers and given guest lectures 

at several national and international conferences. His email address is 

gsamtani@ubspw.com. 

IX


Preface 

Changing Business Landscape 

In the present day digital economy, business values and competitive 

advantages lie beyond the boundaries of the enterprise, focusing on the 

relationships with business partners. The changing business landscape 

not only affects how enterprises conduct business with their suppliers, 

customers, distributors and other trading partners, but also how they 

must manage their businesses internally. 

Collaborative e-commerce, which is the wave of the future, requires 

dynamic creation of trading relationships with new partners, public and 

private business process automation and increased adaptability and 

flexibility delivered by open architecture based integration middleware. 

In order to truly automate external trading partner interactions, the 

back-end internal business systems of the enterprises need to be 

seamlessly integrated into the same process. 

Transforming an organization to compete in this environment mandates 

enterprise application integration (EAI) and business-to-business 

integration (B2Bi). They are the pervasive enablers of most current 

business strategies, such as collaborative e-commerce, collaborative 

networks, supply chain management (SCM) and customer relationship 

management (CRM) across multiple channels of delivery, including 

wireless devices and the Internet. 

B2Bi strategy should be laid out and executed in such a way so as 

to: have an integrated, real-time application-to-application, system-tosystem 

interaction with all the existing and new trading partners; 

eliminate all manual steps in business processes; conduct secure and 

real-time commerce transactions over the Internet; have the flexibility 

to accommodate the different mode of interactions of each partner; and, 

finally, have the ability to adapt to change — quickly and easily in this 

XI

xii B2B Integration — A Practical Guide to Collaborative E-commerce 

dynamic age of B2B collaborative e-commerce. This is what B2Bi is all 

about — the end-to-end automation and integration of cross-organization 

business processes, data, applications and systems. 

Description of the Book 

B2B Integration (B2Bi) provides a comprehensive guide to the key 

elements of successful B2B integration and collaborative e-commerce 

by highlighting business needs, technologies and development strategies. 

It clarifies and demystifies the intricate dependencies among all the 

components of B2Bi, including integration patterns, enterprise application 

integration (EAI), business process management (BPM), internet security, 

extensible markup language (XML), XML standards, Web services, 

middleware technologies and integration brokers. The book includes 

future technologies that will have a significant impact on B2Bi architectures, 

such as intelligent software agents, wireless technologies and 

peer-to-peer (P2P) computing. Furthermore, it includes in-depth discussion 

of B2Bi-enabled applications such as supply chain management, 

e-procurement, e-marketplaces and collaborative networks. Finally, the 

book provides a suitable framework for the design, development and 

implementation of B2B integration, along with several real world case 

studies. This framework is based on the latest XML standards defined 

in the B2B domain, such as RosettaNet, ebXML and Web services, to 

support cross-organization business processes, data, applications and 

systems. 

In crux, the book provides practical guidelines to companies so as to 

rapidly implement a successful B2Bi strategy and prepare them for the 

next wave of B2B integration and collaborative e-commerce. 

Why This Book? 

There are several books on the shelves, which cover just one or the 

other aspect of B2Bi. But I dare say there are none that discuss all the 

technical and business components, tools and frameworks of B2Bi 

and illustrate how to conceptualize and implement a successful B2B 

integration solution, all in one single binding.

Preface xiii 

In this book, I ventured to take a unique and systematic approach of 

combining the technical and business aspects of all the components of 

B2B integration. I have endeavored to show where and how the individual 

components link with one another and in the whole chain of B2Bi. 

The book covers a mix of business management and technology 

trend issues, presented with examples, general conclusions and recommendations. 

The book discusses how companies can speak the same 

language when doing business with companies spread around the globe. 

It presents business integration models, which would enable companies 

to integrate their enterprise systems with digital markets and strategic 

business partners. It also prompts one to "imagine the future" through 

an in-depth analysis of possible scenarios for future business-to-business 

integration models. 

Who Should Read This Book? 

This book will be useful for business executives, MBA students, IT 

managers and programmers looking for a clear, detailed explanation of 

the whole landscape of B2B integration, insightful review of the current 

technologies being used in B2Bi and knowledge of the future trends in 

B2Bi domain. It will be equally appealing to the senior management in 

the industrial-age companies, Internet services companies and entrepreneurs 

who are heading for B2Bi, which is still largely undefined and 

cryptic. This book will be useful to CIOs and decision-makers keen to 

improve productivity using B2Bi, while building upon prior investments, 

and prepare them for the next wave of collaborative e-commerce. 

In short, this book is useful to everyone who is seeking a clear 

understanding of how to leverage the convergence of IT with business 

processes to attain the much sought-after strategic advantage, greater 

revenue, greater profit and more-competitive market positioning. 

How is This Book Organized? 

This book is modeled on an architectural design, laying the foundation 

first and then building the structure with distinct elevation features.

xiv B2B Integration — A Practical Guide to Collaborative E-commerce 

The organization of chapters is as follows: 

Chapter 1 — Introduction 

This chapter introduces the subject of B2Bi and collaborative e-commerce, 

providing a roadmap for a successful B2Bi implementation. It covers 

the key features required in a B2Bi solution and its return on investment 

(ROI). 

Chapter 2 — Components, Benefits, Challenges and 

Applications of B2B Integration 

This chapter provides an overview of all the major components of 

B2Bi. It discusses the benefits enterprises would reap and the obstacles 

they may be confronted with during the process of implementation of 

B2Bi. Furthermore, it introduces some of the most important B2Bienabled 

applications to the readers. 

Chapter 3 — Integration Patterns 

This chapter explains the different types of B2B integration patterns: 

data oriented integration (data replication; extract, load and transform 

solution; data warehousing; and data federations), portal oriented 

integration, direct application integration (API, RPC processes) and 

business process oriented integration (closed and open processes). It 

discusses the right B2Bi implementation pattern for individual companies. 

Chapter 4 — Enterprise Application Integration (EAI) 

This chapter describes the integration of internal systems, such as 

legacy applications, CRM, SCM and ERP, which constitute the backbone 

of B2Bi implementation. It also provides an introduction of the leading 

commercial EAI brokers and convergence and divergence of EAI and 

B2BL

Preface xv 

Chapter 5 — Business Process Management (BPM) 

This chapter discusses the fundamentals of business process management 

(BPM) as they relate to B2Bi. It provides an in-depth discussion on 

process modeling, workflows, workflow management and leading BPM 

software solutions. 

Chapter 6 — Extensible Markup Language (XML) 

This chapter provides an introduction to extensible markup language 

(XML) and its components. It also discusses the traditional mode of 

communication electronic data interchange (EDI), its coexistence with 

XML and features of XML/EDI servers. 

Chapter 7 — XML Standards For E-business 

This chapter is devoted to the description of different XML standards 

that enable XML-based, cross-organization business process integration. 

It covers RosettaNet, ebXML, cXML, SOAP and BizTalk with elaborate 

examples. 

Chapter 8 — Middleware Technologies 

This chapter reveals all the major middleware technologies, using which 

B2Bi solutions are implemented. It specifically discusses TP monitors, 

message oriented middleware (JMS, MQSeries) and distributed objects 

and components (J2EE, COM+, CORBA). 

Chapter 9 — Integration Brokers 

This chapter explains all the components, architectures and services of 

integration brokers. It also introduces all the major commercial integration 

brokers enabling B2Bi from BEA Systems, IBM, Vitria and webMethods.

xvi B2B Integration — A Practical Guide to Collaborative E-commerce 

Chapter 10 — Internet Security 

This chapter dwells upon the security aspects of B2Bi. It explains the 

different types of security solutions for B2B transactions over the 

Internet, along with real world case studies. 

Chapter 11 — Web Services 

This chapter brings in the latest concept in the B2B world — Web 

services. It explains the subject with supporting technologies — UDDI, 

WSDL, WSFL and SOA with adequate examples. 

Chapter 12 — Wireless Technologies 

This chapter focuses on the explosive growth of wireless technologies 

for B2B e-commerce and its impact on B2Bi architectures. It also 

details technologies such as WAP, WML and WMLScript, along with 

explanations of security aspects involved in mobile systems. 

Chapter 13 — Software Agents 

This chapter describes the fundamentals of software agents and how 

they automate the manual processes that are involved today in B2B 

e-commerce. 

Chapter 14 — Supply Chain Management (SCM) 

This chapter deals with the fundamentals of supply chain management 

(SCM), e-procurement, e-logistics, SCM systems and how SCM enables 

collaborative e-commerce. 

Chapter 15 — E-marketplaces and 

Collaborative Networks 

This chapter brings under focal analysis the different types of B2B 

e-marketplaces along with services offered by them. It discusses the 

integration challenges that crop up while participating in e-marketplaces.

Preface xvii 

It also introduces the need, concepts and examples of collaborative 

networks. 

Chapter 16 — B2B to P2P Evolution 

This chapter deals with the evolution of peer-to-peer-based applications 

and architectures that would play a prominent role for B2Bi in the future. 

Features of the Book 

Some of the key features of the book include: 

Key concepts 

Each chapter begins with a discussion of the key concepts related to the 

subject under study. Readers will find this very useful as it introduces 

the ensuing chapters. 

Discussion of leading software solutions 

The book provides in-depth coverage of the latest commercial softwares 

available in the market. This will acquaint readers with the developments 

in the software industry as far as B2B integration solutions are concerned. 

It will also be extremely helpful to the decision-makers to have a 

review of various solutions for B2Bi out there. 

Case studies 

There are several real world case studies cited in each chapter. They 

have been chosen very carefully to illustrate practical usage of the 

concepts under focus. 

Graphics/Images 

The book contains a lot of relevant images, which provide a pictorial 

view of the text concerned. Readers will find the images very illustrative 

and useful in grasping the theory presented therein.

xviii B2B Integration — A Practical Guide to Collaborative E-commerce 

Acronyms 

The book contains acronyms of technical and business terms that are 

relevant to the subject of B2B integration. 

References/Bibliography 

The book acknowledges various sources used by giving references and 

a bibliography. This will help readers to plumb the originals if they so 

desire. 

Editors and Contributors 

I consider myself extremely fortunate in having got the invaluable 

support and able guidance of several persons from different walks of 

life. They are distinguished professionals who have carved a niche for 

themselves in their respective fields. Undoubtedly, their contribution 

has embellished this book. It is my privilege to give hereunder a pen 

portrait of these contributors. 

Dr. Marcus Healey 

Dr. Marcus J. Healey is the Strategy Consultant for InfoFirst Inc., USA. 

Before joining InfoFirst, Dr. Healey was the Director of Engineering 

Implementation at Mobilocity, Inc., U.S., a thought leader in wireless 

services. Prior to Mobilocity, Dr. Healey was a Project Engineer at 

Organic, Inc., a prominent web integrator in New York City. While at 

Organic, Marcus managed client projects from an implementation 

perspective and acted as a technical liaison to the Strategic Services and 

Business Development groups. Prior to Organic, Dr. Healey was a 

Program Director and Adjunct Professor at the New lersey Institute 

of Technology where he pioneered the Envirolnformatics program as 

the Director of the New Jersey Program for Information Ecology and 

Sustainability. 

Dr. Healey has six years of direct IT experience, possesses multiple 

MS degrees in science and engineering, an MBA and a Ph.D. He brings 

a diverse technical and business background, broad public and private

Preface xix 

sector experience and extensive editing skills. He is the primary author 

of one book in Environmental Science (Pollution Prevention Opportunity 

Assessments, John Wiley & Sons © 1998) and one of four co-authors 

on a soon to be published book (Information Mining on the World Wide 

Web, Kluwer Publishers © 2001). Dr. Healey is the author of over fifty 

publications and presentations in the fields of Environmental Science 

and Information Technology. 

Dr. Shyam Samtani 

Dr. Shyam Samtani is presently Head of the Department, P.G. Department 

of English, Indore Christian College, Indore (India). He is also on the 

visiting faculty of Devi Ahilaya University, Indore. He has been in the 

teaching profession for the last 35 years. During this period he has 

supervised scores of dissertations both at M.A. and M.Phil levels. He 

has presented papers at various national seminars and also published 

many research papers and supervised Ph.D candidates. He has coauthored 

books for use by university students. He has also been a 

Resource Person for the Refreshers/Orientation courses conducted by 

different universities. Dr. Shyam Samtani has done the language editing 

of this book. 

Pawan Samtani 

Pawan Samtani has over eleven years of IT, MIS and Finance experience. 

He has extensive experience in different industries like E-commerce 

Consulting, Oil and Gas, Manufacturing and Finance. He is currently 

working as Country Operations Manager, India, with Oracle Corporation, 

overlooking the implementation of various multi-million dollar projects. 

Prior to joining Oracle, Pawan was the Senior Vice President with 

Petrogas LLC where he was overseeing the implementations of Ariba 

e-Marketplace and Oracle Financials in several offices of the company 

all around the world. His responsibilities include project management, 

strategic planning and supervising finance operations. 

Prior to Petrogas, he was working as a Senior Consultant with 

Whittman Hart, U.S., supervising several SAP implementations world 

over. He has worked with Premira Fashions Limited, Onida Finance

xx B2B Integration — A Practical Guide to Collaborative E-commerce 

Limited, Analysis Finance Limited and M. Mehta & Company, Chartered 

Accountants, in various capacities. 

He has extensive experience with the re-engineering of business 

practices for various departments. He also specializes in implementing 

and customizing ERP packages to integrate with the business process, 

workflow and existing IT applications of the company. He possesses indepth 

knowledge of data modeling and database schema designing, 

supply chain management, logistics systems and their integration with 

e-commerce. He has worked with reputed concerns in different parts of 

the world (United States of America, India and The Middle East) with 

different business practices and cultures. 

He is an Associate Member of Chartered Accountants of India. He 

also has an MBA from Baruch College, New York, U.S. 

Kenneth Tamburello 

Ken Tamburello is a Senior Consultant Specialist at Bluesphere (an 

EDS company), U.S., the industry's largest interactive integrator and 

e-business consulting firm. Ken is the e.Design and e.Marketing delivery 

manager for the New York Metro region, responsible for delivering 

solutions in the areas of Enterprise Application Integration (EAI), 

workflow automation, security and enterprise portals. 

Prior to Bluesphere, Ken was an Associate Director at Bear Stearns 

& Co., NY, where he was responsible for the delivery, support and 

enhancement of a mission-critical, multi-million dollar Web-based account 

portfolio database system. Prior to Bear Stearns, Ken was a freelance 

consultant designing and developing client-server solutions. 

Ken has over 6 years IT experience, having worked in the past with 

PowerBuilder, Sybase, Oracle, UNIX, Java, UML and database design and 

modeling. He received his MS in Engineering from Stevens Institute of 

Technology, U.S., and his BS in Engineering from Rutgers University, U.S. 

Deepak Bajaj 

Dr. Deepak Bajaj is the Course Coordinator of Project Management at 

the University of Technology Sydney (UTS). Dr. Bajaj served as Director 

of the Project Management Program prior to his present role.

Preface xxi 

Dr. Bajaj has fifteen years of combined experience in contracting, 

consulting and academia. Dr. Bajaj has a PhD in the area of strategic 

risk management and the topic of 'The Development of a Risk Averse 

Business Strategy in the Procurement of Constructed Facilities' and a 

Masters in Construction Management. He brings a diverse technical, 

research and business background. He has published extensively in the 

area of project risk management and has been author and co-author of 

book chapters in the past. He has been editor of the AIQS Refereed 

Journal and referee to a number of journals in the area of project 

management and economics. Dr. Bajaj is the author of over forty 

publications and presentations in the field of project management, risk 

management and information technology in the construction industry. 

Dimple Sadhwani 

Dimple Sadhwani is Senior Software Engineer at Island ECN based in 

New Work, USA. Prior to joining Island, Dimple worked as a Senior 

E-commerce Consultant with BusinessEdge Solutions, a next-generation 

consulting firm providing industry-specific e-business solutions. She was 

a project manager for several eCRM, B2B integration and EAI projects. 

Prior to that she worked with Citicorp Information Technology Industries 

Ltd. (CITIL), based in New Jersey, USA, and Bombay, India. She has a 

Bachelors in Computer Science from VJTI, Bombay. She has worked 

on and evaluated the latest tools and solutions in the B2B, EAI and 

Internet security fields. 

Not the Final Word 

Justice can hardly be done to such an elaborate subject with all its 

dimensions and ramifications, on an intensive or extensive scale, in a 

book of this length. It would require more than one volume to cover the 

subject exhaustively. The endeavor is to acquaint the readers with the 

concepts in a nutshell in one place without having to wander about to 

different sources for various topics related to B2Bi. 

I wish I could promise you a book perfect in every way. There are 

bound to be some errors, omissions and typographical errors. I am open

xxii B2B Integration — A Practical Guide to Collaborative E-commerce 

to corrections and modifications. I shall appreciate critical opinions and 

objective suggestions from the esteemed knowledgeable readers, which 

would shed light my future undertakings. The suggestions can be sent 

to me via e-mail at: 

gunjan_samtani@yahoo.com or gsamtani@ubspainewebber.com 

I will respond immediately. Well, that's it for now. I would like to 

welcome you to the exciting world of B2B integration. Good luck! 


New Jersey, USA 

April 2002

Contents 

Dedications v 

Acknowledgements vii 

About the Author ix 

Preface xi 

Part I The Big Picture 1 

Chapter 1 Introduction 3 

1.1. Evolution of Next Generation Enterprises 4 

1.2. New Rules of Engagement 4 

1.3. B2B E-Commerce 5 

1.3.1. What is B2B e-commerce? 5 

1.3.2. B2B vs. B2C: Differing strategies 6 

1.3.3. Explosive growth in B2B 

e-commerce 6 

1.3.4. What is collaborative e-commerce? 8 

1.4. B2B Integration (B2Bi) 9 

1.4.1. Integration: The top priority 10 

1.4.2. A daunting effort 12 

1.4.3. Getting beyond the starting line 13 

1.4.4. Selecting the right B2Bi solution 17 

1.5. What is the Return on Investment (ROI) on 

B2Bi? 20 

1.6. Conclusion 23 

Chapter 2 Components, Benefits, Challenges and 

Applications of B2B Integration 24 

2.1. The Word is Out 25 

2.2. B2Bi Components 25

xxiv B2B Integration — A Practical Guide to Collaborative E-commerce 

2.2.1. Integration patterns 

2.2.2. Enterprise Application Integration 

(EAI) 

2.2.3. Business Process Management 

(BPM) 

2.2.4. Extensible Markup Language 

(XML) 

2.2.5. XML standards for e-business 

2.2.6. Web services 

2.2.7. Middleware technologies 

2.2.8. Integration brokers 

2.2.9. Internet security 

2.2.10. Wireless technologies 

2.2.11. Software agents 

2.3. Benefits of B2B Integration 

2.3.1. Dynamic business relationships 

2.3.2. Real-time information 

2.3.3. Lower transaction costs 

2.3.4. Participation in online 

marketplaces 

2.3.5. Streamline business operations 

2.3.6. XML-based integration 

2.3.7. Increased customer service and 

retention 

2.3.8. Opportunity to re-architect 

internal systems 

2.4. B2Bi Challenges 

2.4.1. Internal application integration 

2.4.2. Disparate internal corporate data 

2.4.3. System heterogeneity 

2.4.4. Data security 

2.4.5. Transaction integrity 

2.4.6. Internal business process 

management 

2.4.7. Inter-enterprise business process 

integration 

2.4.8. Internal resistance 

25 

26 

27 

27 

29 

29 

30 

30 

30 

31 

32 

32 

32 

33 

33 

34 

34 

34 

34 

35 

35 

36 

37 

38 

38 

38 

39 

39 

39

Contents xxv 

2.4.9. Standards and industry issues 40 

2.4.10. Distributed control 40 

2.4.11. Performance and scalability 40 

2.4.12. Expensive 41 

2.4.13. 24/7 availability of the system 41 

2.5. B2Bi-Enabled Applications 41 

2.5.1. Supply Chain Management (SCM) 41 

2.5.2. E-marketplaces and collaborative 

networks 42 


Part II Established Integration Components 45 

Chapter 3 Integration Patterns 47 

3.1. Types of Integration 48 

3.2. Data Oriented B2B Integration 49 

3.2.1. Data replication 50 

3.2.2. Extract, Transform and Load 

(ETL) solution 54 

3.2.3. Data warehouses and data marts 59 

3.2.4. Multi-database server 60 

3.2.5. XML and databases 65 

3.2.6. Data oriented integration and B2Bi 67 

3.3. Portal Oriented Integration 68 

3.3.1. Types of portals 69 

3.3.2. Components of a portal server 

platform 70 

3.3.3. Portal oriented integration and 

B2Bi 74 

3.4. Application Oriented Integration 74 

3.4.1. Application Programming 

Interfaces (APIs) 75 

3.4.2. Remote Procedure Calls (RPCs) 82 

3.4.3. Application oriented integration 

and B2Bi 88 

3.5. Business Process Integration (BPI) 89 

3.5.1. Business process integration 

patterns 89

xxvi B2B Integration — A Practical Guide to Collaborative E-commerce 



3.6. Which Approach to Use for Your B2Bi 

Implementation? 93 

3.6.1. Agreement among the trading 

partners 93 

3.6.2. Your integration goals 93 


Chapter 4 Enterprise Application Integration (EAI) 96 

4.1. Today's Enterprise 97 

4.2. What is EAI? 97 

4.3. Where Did Things Go Wrong? 98 

4.4. Benefits of EAI 100 

4.4.1. A word of caution 101 

4.5. Types of EAI 102 

4.5.1. User interface integration 

(Refacing) 102 

4.5.2. Data integration 103 

4.5.3. Function or method integration 103 

4.5.4. Business process integration 104 

4.6. Types of Enterprise Systems 105 

4.6.1. Legacy systems 105 

4.6.2. Client/server systems 106 

4.6.3. Enterprise Resource Planning (ERP) 106 

4.6.4. Customer Relationship 

Management (CRM) 111 

4.6.5. eCRM 113 

4.6.6. CRM and EAI 115 

4.6.7. Supply Chain Management (SCM) 115 

4.7. Leading EAI Solutions 115 

4.7.1. BEA eLink 115 

4.7.2. TIBCO ActiveEnterprise 116 

4.7.3. IBM — WebSphere MQ integrator 118 

4.8. Convergence of EAI and B2Bi 121 

4.9. Divergence of EAI and B2Bi 122 

4.10. Conclusion 123

Contents xxvii 

Chapter 5 Business Process Management (BPM) 125 

5.1. Existence of 'Organization Silos' 126 

5.2. Fundamentals of BPM 126 

5.2.1. Business processes 126 

5.2.2. Participants 130 

5.2.3. Activities 130 

5.2.4. Business transactions 130 

5.2.5. What is BPM? 132 

5.2.6. Workflow 133 

5.2.7. Roadmap to BPM 134 

5.3. BPM Systems 139 

5.3.1. BEA WebLogic integration 142 

5.3.2. Vitria BusinessWare 143 

5.3.3. Extricity B2B Alliance Manager 144 

5.4. Universal Language for BPM 147 

5.4.1. Business Process Management 

Initiative (BPMI) 148 

5.4.2. XLANG 149 

5.5. Standard Business Processes 149 


Chapter 6 Extensible Markup Language (XML) 152 

6.1. The Need for a Universal Language 153 

6.2. What is Electronic Data Interchange 

(EDI)? 154 

6.2.1. How does it work? 154 

6.2.2. Limitations of traditional EDI 155 

6.3. What's Wrong with the First Language of 

the Internet — HTML? 157 

6.4. XML: The Universal Language of Data 

Interchange 158 

6.4.1. The power to know 159 

6.4.2. What is XML? 160 

6.4.3. XML: A derivative of SGML 161 

6.4.4. Sample XML files 161 

6.4.5. XML strengths 163 

6.4.6. XML limitations 166

xxviii B2B Integration — A Practical Guide to Collaborative E-commerce 

6.4.7. XML namespaces 167 

6.4.8. Brief introduction to the 

components of XML 168 

6.4.9. Advantages of XML over 

traditional EDI 174 

6.5. XSL — Extensible Stylesheet Language 175 

6.6. Coexistence of XML and EDI 178 

6.6.1. EDI is here to stay 178 

6.6.2. EDI based on XML 179 

6.6.3. Characteristics of XML/EDI 180 

6.6.4. Benefits of XML/EDI over 

traditional batch EDI 181 

6.6.5. Key features of XML/EDI server 182 


Chapter 7 XML Standards for E-business 187 

7.1. Standards Imperative for B2B Application 

Integration 188 

7.2. RosettaNet's Solution 189 

7.2.1. What is RosettaNet? 189 

7.2.2. Components of RosettaNet's 

e-business solution 190 

7.2.3. Benefits of using RosettaNet 

solution 196 

7.2.4. RosettaNet embraced by software 

vendors 197 

7.2.5. What's the ROI (Return on 

Investment) in implementing 

RosettaNet solution? 198 

7.3. FpML — Financial Products Markup 

Language 200 

7.3.1. What is FpML? 200 

7.3.2. Benefits of FpML 200 

7.4. Commerce XML (cXML) 202 

7.5. Electronic Business XML (ebXML) 204 

7.6. Simple Object Access Protocol (SOAP) 205 

7.6.1. SOAP messages 205

Contents xxix 

7.7. BizTalk Framework 207 

7.7.1. Components of the BizTalk 

Framework 207 

7.7.2. The envelope 208 


Chapter 8 Middleware Technologies 213 

8.1. What is Middleware? 214 

8.2. Transaction Processing (TP) Monitors 216 

8.2.1. How they work? 217 

8.2.2. Benefits of TP monitors 218 

8.3. Message Oriented Middleware (MOM) 219 

8.3.1. Why use message queues? 221 

8.3.2. Types of communication 222 

8.3.3. MOM frameworks 224 

8.3.4. MOM middleware 226 

8.4. Distributed Objects and Components 231 

8.4.1. Distributed components 233 

8.4.2. Distributed object frameworks 234 

8.4.3. OMA — CORBA 3 235 

8.4.4. Windows DNA — COM+ 239 

8.4.5. J2EE — EJB 244 

8.4.6. J2EE application servers 249 


Chapter 9 Integration Brokers 254 

9.1. Introduction 255 

9.1.1. Integration brokers enable 

(best-of-breed) BOB approach 256 

9.2. Architecture of Integration Brokers 256 

9.2.1. Hub-and-spoke architecture 256 

9.2.2. Message bus architecture 257 

9.2.3. Multi-hub architecture 258 

9.3. Components of Integration Brokers 259 

9.3.1. Messaging services 260 

9.3.2. Application adapters 262 

9.3.3. Data transformation component 264 

9.3.4. Workflow manager 266

xxx B2B Integration — A Practical Guide to Collaborative E-commerce 

9.3.5. Metadata repository 

9.3.6. Administration tool 

9.4. Services of Integration Brokers 

9.4.1. Enable all types of integration 


9.4.3. Interoperability 

9.4.4. Open architecture 

9.4.5. Support for all communication 

protocols 

9.4.6. Directory services 

9.4.7. Trading partner management and 

personalization 

9.4.8. Security 

9.4.9. Scalability 

9.4.10. Transactional integrity 

9.4.11. Integration broker connectivity 

9.5. Selecting an Integration Broker for Your 

Company 

9.6. Leading Integration Brokers 

9.6.1. Microsoft BizTalk Server Suite 

9.6.2. SeeBeyond eBusiness Integration 

Suite 

9.6.3. webMethods B2B platform 

9.6.4. BEA WebLogic integration 

9.6.5. ROI on integration brokers 

9.7 Conclusion 

266 

266 

267 

267 

268 

268 

268 

268 

269 

269 

270 

270 

270 

271 

273 

274 

274 

278 

279 

283 

285 

285 

Chapter 10 Internet Security 287 

10.1. Internet Security (E-Security) Critical 

for B2Bi 288 

10.2. B2Bi — Makes a Company Highly 

Vulnerable to Security Risks 289 

10.2.1. Complex nature of applications 289 

10.2.2. Anonymous relationships in B2B 


10.2.3. Software undergoing frequent 

change 289 

10.2.4. Human factor involved 290

Contents xxxi 

10.3. Employees and Other Insiders Pose the 

Biggest Threat 290 

10.4. E-Security Strategy 291 

10.5. Basic Security Services in B2Bi 291 

10.5.1. The strength of the chain is as 

strong as its weakest link 292 

10.6. Key Concepts in E-Security Solutions 293 

10.6.1. Cryptography 293 

10.6.2. Private key encryption 294 

10.6.3. Public key encryption 295 

10.6.4. Best of both worlds — The digital 

envelope 296 

10.6.5. Digital signature 296 

10.6.6. Digital certificates and role of 

Certificate Authorities (CAs) 300 

10.6.7. Using SSL (Secure Sockets Layer) 

to establish secure sessions 301 

10.7. Shielding an Organization from the 

Outside World 302 

10.7.1. Firewalls 302 

10.7.2. Functions performed by firewalls 303 

10.7.3. Types of firewalls 304 

10.7.4. Considerations in choosing a 

firewall 306 

10.7.5. Enterprise firewall appliance 306 

10.7.6. Virtual Private Networks (VPNs) 308 

10.7.7. Check Point's VPN solution 310 

10.8. B2Bi and E-Security 311 

10.8.1. Revamp your security 311 

10.8.2. B2Bi software 312 

10.8.3. Security features in the leading 

B2B integration servers 313 

10.8.4. E-security tailored to XML 314 

10.9. Secure Payments Over the Internet 315 

10.9.1. Need for trusted third party entities 316 

10.10. Security Trends for the Future 317 


xxxii B2B Integration — A Practical Guide to Collaborative E-commerce 

Part III Evolving Integration Components 323 

Chapter 11 Web Services 325 

11.1. Service Oriented Architecture (SOA) 326 

11.1.1. Components and operations 

of SOA 326 

11.2. What are Web Services? 327 

11.2.1. Application of SOA-based 

framework to B2Bi 328 

11.3. Essential Features of a Web Services 

Environment 329 

11.4. Universal Description, Discovery and 

Integration (UDDI) 330 

11.4.1. What is UDDI? 330 

11.4.2. UDDI built on SOAP 331 

11.4.3. UDDI data structure 331 

11.4.4. UDDI APIs 333 

11.5. Web Services Description Language 

(WSDL) 333 

11.5.1. WSDL schema 334 

11.5.2. WSDL and UDDI 334 

11.6. Web Services Flow Language (WSFL) 335 

11.7. Putting Everything Together 335 


Framework 336 

11.9. Security Requirements for Web Services 337 

11.9.1. Authentication 338 

11.9.2. Authorization 338 

11.9.3. Data protection 338 

11.9.4. Non-repudiation 338 

11.10. Where to Start? 339 

11.10.1. Leverage existing assets 339 

11.10.2. Build an internal repository for 

web services 340 

11.10.3. Bottom line 340 

11.11. Web Services Networks 340 


Contents xxxiii 

Chapter 12 Wireless Technologies 342 


12.2. The Wireless Internet Today 344 

12.2.1. Definition and growth 344 

12.2.2. Mobile benefits 345 

12.3. Wireless Application Architecture and 

Components 347 

12.3.1. Wireless Access Protocol (WAP) 350 

12.3.2. Wireless Markup Language 

(WML) 351 

12.3.3. WMLScript 352 

12.4. Wireless Security Issues 353 

12.4.1. Security of mobile systems 353 

12.4.2. Security issues in WAP 355 

12.4.3. Generic mobile solutions 358 

12.5. B2B Wireless Applications 360 

12.5.1. Business uses of the mobile 

Internet 360 

12.5.2. B2B wireless portals 362 

12.5.3. On-demand trading 363 

12.5.4. Business-to-Employee (B2E) 

connections 363 

12.5.5. B2B, B2C, B2E and wireless 365 

12.6. Enterprise Integration Issues for 

M-commerce 366 

12.7. Leading M-commerce Solution Providers 369 

12.7.1. BEA WebLogic m-commerce 

solution 369 

12.7.2. IBM's WebSphere everyplace 

suite 372 

12.8. To be or not to be... Wireless: Pertinent 

Strategic Considerations 372 

12.8.1. Goal and business definition 372 

12.8.2. Formulation of technology 

strategy 374 


xxxiv B2B Integration — A Practical Guide to Collaborative E-commerce 

Chapter 13 Software Agents 381 

13.1. Software Agents Enabling the Formation 

of Virtual Organizations 382 

13.2. What are Intelligent Software Agents? 382 

13.3. What are Agent Systems? 384 

13.4. Agent Classification 384 

13.5. Agents and Autonomy 387 

13.6. Multi-Agent Environment 387 

13.6.1. The 3 Cs of prime importance 388 

13.6.2. Advantages of a multi-agent 

environment 388 

13.6.3. Disadvantages of a multi-agent 

environment 388 

13.7. Agents and Negotiation 389 

13.7.1. Types of negotiation strategies 390 

13.7.2. Not revealing negotiation strategy 

paramount 390 

13.8. Agents and Mobility 391 

13.8.1. Benefits of using mobile agents 391 

13.8.2. Potential risks involved in use 

of mobile agents 392 

13.9. Agents' Role in B2B E-Commerce 


13.9.1. Information gathering and filtering 394 

13.9.2. Uncovering quality sales prospects 395 

13.9.3. Value chain integration 395 

13.9.4. Optimization of business processes 

in light of B2Bi 396 

13.9.5. Efficient e-marketplaces 397 

13.9.6. Maintaining customer relationships 399 

13.9.7. Effective e-procurement 399 

13.9.8. Integration with legacy systems 400 

13.9.9. Enable privacy in B2B transactions 400 

13.10. Need for a Universal Language 402 

13.10.1. XNS: A dictionary and address 

book for web agents 404 


Contents xxxv 

Part IV B2Bi-Enabled Applications 407 

Chapter 14 Supply Chain Management (SCM) 409 


14.2. Fundamentals of Supply Chain 

Management 410 

14.2.1. A few definitions of SCM 410 

14.2.2. What is a supply chain? 411 

14.2.3. A typical business process flow 

in a supply chain 412 

14.2.4. Activities in a supply chain 413 

14.3. Legacy Supply Chain 415 

14.3.1. Push-based supply network 415 

14.3.2. What's wrong in a legacy supply 

chain? 416 

14.4. B2Bi-Enabled Supply Chain 417 

14.4.1. Principles of SCM 418 

14.4.2. Pull-based supply network 419 

14.4.3. ROI in moving from pull-based 

to push-based supply network 420 

14.4.4. Features of B2Bi-enabled supply 

chain 420 

14.5. Supply Chain Planning and Execution 422 

14.5.1. Supply Chain Planning (SCP) 422 

14.5.2. Supply Chain Execution (SCE) 423 

14.5.3. E-procurement — The 

transformation of corporate 

purchasing 424 

14.5.4. E-logistics: Integrating warehouses, 

distribution centers and customer 

interaction processes 427 

14.6. SCM Challenges 428 

14.6.1. Synchronization in supply chain 428 

14.6.2. Building trust through supply 

chain 428 

14.6.3. Operational stability 428 

14.6.4. Inertia for change 429

xxxvi B2B Integration — A Practical Guide to Collaborative E-commerce 

14.6.5. Supply chain complexity 429 

14.6.6. Managing supply chain for short 

lifecycle products 429 

14.6.7. Integration challenge within the 

organization 429 

14.6.8. Integration challenge with supply 

chain partners 430 

14.6.9. Inter-company business process 

synchronization 430 

14.7. SCM Techniques 430 

14.7.1. Vendor Managed Inventory 

(VMI) 431 

14.7.2. Just-in-Time (JIT) 431 

14.7.3. Collaborative Planning, 

Forecasting and Replenishment 

(CPFR) 431 

14.8. SCM Systems 434 


Chapter 15 E-Marketplaces and Collaborative Networks 438 

15.1. What are E-Marketplaces? 439 

15.2. Basics of B2B E-Marketplaces 440 

15.2.1. Pre e-marketplace era 440 

15.2.2. E-marketplace era 440 

15.2.3. Classification of e-marketplaces 441 

15.2.4. Market makers 444 

15.2.5. Dynamic trading through B2B 

e-marketplaces 444 

15.2.6. Governance of e-marketplaces 445 

15.2.7. Benefits of B2B e-marketplaces 445 

15.2.8. Which e-marketplace to join? 449 

15.2.9. B2B e-marketplaces services 453 

15.3. How E-Marketplaces Fit into a Company's 

B2Bi Plans 457 

15.3.1. Catalog publishing 457 

15.3.2. Receiving and processing orders 458 

15.3.3. Data transformation 459

Contents xxxvii 

15.3.4. Integrating credit, financing and 

collection system with ERP 460 

15.4. Emergence of B2B Collaborative Networks 460 

15.4.1. Just another point of connection 460 

15.4.2. Lack of support for collaborative 

commerce 462 

15.4.3. B2B collaborative networks 462 


PartV Conclusion 467 

Chapter 16 B2B to P2P Evolution 469 

16.1. Why Peer-to-Peer? 470 

16.1.1. Let your imagination run wild 470 

16.1.2. What is P2P? 471 

16.1.3. What is a peer group? 471 

16.1.4. Features of a P2P application 471 

16.2. Leading P2P Protocols 473 

16.2.1. Jabber 473 

16.2.2. Juxtapose — JXTA 474 

16.3. Examples of P2P Applications 477 

16.3.1. NextPage — NXT 3 477 

16.3.2. FirstPeer — Professional servant 478 

16.3.3. Groove networks — Groove 1.0 478 

16.3.4. Gnuetella 478 

16.3.5. Applied MetaComputing — 

Legion 478 

16.4. Benefits of P2P-Based Applications in 

B2B Integration 479 

16.4.1. Collaboration 479 

16.4.2. Enhanced performance 479 

16.4.3. Intelligent agents 481 

16.4.4. P2P marketplaces 481 

16.4.5. Information discovery using 

search engines 483 

16.4.6. Eliminate the need for cataloging 

in multiple formats 483

xxxviii B2B Integration — A Practical Guide to Collaborative E-commerce 

Acronyms 

16.5. But the Road is Winding 

16.5.1. Network bandwidth 


16.5.3. Complex architectures and 

difficult maintenance 

16.6. Conclusion 

Appendix 

A. PIP2A1: Distribute New Product Information 

B. UDDI Technical White Paper 

Bibliography 

Index 

484 

484 

484 

485 

485 

487 

493 

519 

531 

541

Part I 

The Big Picture 

i


Chapter \ 

Introduction 

The focus of this chapter 

With B2B integration, collaborative e-commerce will truly come to life 

— moving from the phase of revolutionary idea to becoming a common 

aspect of business operations. 

In this chapter, we will introduce the subject of B2B collaborative 

e-commerce, differences between B2B and B2C, concepts of B2B 

integration, formulation of B2Bi strategy, the roadmap to a successful 

B2B integration strategy and implementation, features of a good B2B 

integration solution and return on investment on B2Bi implementation. 

3

4 B2B Integration — A Practical Guide to Collaborative E-commerce 

1.1. Evolution of Next Generation Enterprises 

The Center for Research in Electronic Commerce (CREC), at the 

University of Texas-Austin recently conducted a large study to assess 

collaborative e-business value in small, medium and large companies 

across the U.S. and Europe. The study, which included leading manufacturers, 

retailers, distributors and wholesalers, identified a strong 

link between e-business drivers such as system integration, customer 

and supplier oriented processes, financial indicators and operational 

excellence measures. It reveals that many companies have either not 

engaged in B2B collaborative e-commerce or just started to move 

towards it. The study indicates that most companies have only scratched 

the surface of e-business and have yet to realize the gains in efficiency 

and productivity that can be achieved through using the Internet. 

But a few companies are going through a phase of Internet revolution 

in terms of restructuring their business processes, providing real-time 

customer service, integrating their internal applications and supply chain. 

They are increasing their profitability through digitization and integration 

of business processes — especially in business-to-business transactions. 

They are flexible, adaptable and eager to change, and have an unprecedented 

global market access of 24/7/365. They are utilizing their 

investments in e-business initiatives to achieve operational excellence. 

These are a new class of companies, known as Next Generation 

Enterprises (NGEs) that will dominate tomorrow's markets. 

Companies that are not participating in this revolution may not 

remain competitive and profitable in the future. Becoming the next 

generation enterprise is not a matter of choice anymore. No modern 

business, regardless of its size, can survive without digitizing business. 

Your company can join the race, or get ousted by the competition. It is 

still not too late — the long-term race has just begun. 

1.2. New Rules of Engagement 

The e-business world is growing at an unprecedented pace. Businesses 

all over the world are realizing that future survival and success are 

dependent upon the collaborative commerce capabilities of the 

organization and its ability to act at Internet speeds. The new dimensions

Introduction 5 

of business will involve robot shopping agents, business process 

coordination, business-to-business exchanges, collaborative networks, 

online billing, auctions, digital cash, mass customization, markets for 

trust, cyberization of markets and concepts yet to be invented. Companies 

in many sectors of the economy will be forced to adapt to these new 

market realities with improved information technology infrastructures 

as well as automated and re-engineered business processes. 

The new rules of engagement, enforced by the new online economy, 

require a complete transformation of a legacy company to an e-business 

driven company. Technology plays a vital role in this transition and 

transformation and it is changing from a cost of doing business to a 

way of doing business. 

However, companies cannot, and should not abandon the classic 

concepts of successful business: product, price, promotion and place — 

or channel synergy — as well as customer service and fulfillment. What 

is required for survival in the new economy is an appropriate balance 

between established business practices and the implementation of today's 

information technology. The next generation enterprises will be successful 

only through the right integration of technology and business processes. 

1.3. B2B E-Commerce 

B2B e-commerce is being talked about everywhere. And it is not just 

jargon — it is the next level in the e-business revolution, when businesses 

collaborate with business partners in real-time and put management of 

all their processes online — from supply chain and purchasing to 

manufacturing and product development — for increased control, rapid 

response, improved efficiency, global intelligence and unprecedented 

cost savings. B2B e-commerce is a revolution, similar in magnitude to 

the Industrial Revolution, that will fundamentally change relationships 

among business partners — how they exchange information, collaborate, 

communicate and close transactions. 

1.3.1. What is B2B e-commerce? 

B2B e-commerce is an acronym for business-to-business, a type of 

e-commerce involving a transaction from one business to another via


the Internet. Thus, it occurs when systems of two or more businesses 

exchange information electronically that, directly or indirectly, results 

in a transaction. Multiple organizations can exchange information as 

part of a single transaction. A transaction in B2B e-commerce can 

involve traditional purchases and other related business activities such 

as request for a quote, setup of new accounts, order management and 

status information. A transaction generally is real-time, but based on the 

transaction requirement, the aggregation and distribution of data across 

companies may not be real-time. 

B2B e-commerce can be as basic as a manufacturer putting up a 

bare-bones Internet site to let distributors securely order a handful of 

products, or it can be as complex as a distributor offering companyspecific 

pricing and content, complex product configurations and realtime 

access to inventory levels for its entire product line to thousands 

of customers. 

1.3.2. B2B vs. B2C: Differing strategies 

Table 1.1 shows the major differences between B2B and B2C. 

1.3.3. Explosive growth in B2B e-commerce 

Several fundamental forces have driven the explosive growth of B2B 

e-commerce. Some of these forces arise from the need for global trade, 

dynamic business relationships, elimination of price differences, collaboration 

in new products development, forecasts and replenishments and 

movement to market-driven economies. Though price and functionality 

remain critical, customer service and value-added relation-ships have 

become the new drivers of commerce and competitive advantage. 

Forrester Research has estimated that in the U.S. B2B e-commerce 

will grow to more than $2 trillion by 2003, about 10% of business 

sales overall. According to the Gartner Group, the B2B e-commerce 

marketplace will exceed $7 trillion in 2004. North America's share 

will approach $2.8 trillion of market revenue; Europe will grow to 

$2.3 trillion; Asia will account for $900 billion; and Latin America will 

reach $124 billion.

Commerce 

Activities 

Business 

Models 

Nature of 

Transactions 

Order Size 

Table 1.1. Differences between B2B and B2C 

Business to Business (B2B) 

Business-to-business 

encompasses many other types 

of activities than simply placing 

orders between businesses (e.g., 

joint design, development and 

manufacture). For these issues, 

there is a need to agree on 

platforms and/or data 

interchange standards. 

Typical activities among 

companies participating in B2B 

commerce include collaborative 

planning and forecasting, order 

fulfillment, payment execution 

and status tracking. 

The business models in B2B 

are much more defensible than 

in B2C. B2B is an evolved 

economy. It is about transformation 

and evolution of 

business. In B2B, buyers and 

suppliers are made more 

efficient, competitive and 

profitable. 

B2B orders are governed by 

the complex business rules of 

the different parties (such as 

buyers, sellers and distributors) 

involved in the transaction. 

Each side wants visibility in 

the transaction from inception 

to completion. 

In most cases, the average 

order size (in value) in the 

B2B world is large. 


Business to Consumer (B2C) 

For the business-to-consumer, 

the business only has to be 

able to support communications 

via the Internet, phone, fax 

and e-mail. The focus is on 

providing services such as 

product catalogs, ordering and 

payment and status checking. 

The B2C models are based on 

optimizing the ability to 

directly attract, manage and 

support the individual 

customer, thus eliminating the 

traditional middleman. 

In B2C, it is a case of new vs. 

old: it is Amazon vs. Borders. 

They are fighting for a share 

of the same customer. 

B2C orders are often impulse 

or spot transactions with a 

short life span. There is more 

leniency in fulfillment of these 

orders. 

In most cases, the average 

order size (in value) in the 

B2C world is small.


Flexibility to 

Change 

Relationships 

Customer 

Relationships 

Table 1.1 (Continued) 

Business to Business (B2B) 

The switching costs in B2B are 

much higher because the 

companies are much more 

tightly connected through 

integration into back office 

ERP systems. The companies 

must evolve business processes 

and develop trust with buyers 

and suppliers that goes well 

beyond delivering a product. 

Relationships are much more 

complex, long-term, often 

contractual and involve bigger 

dollar amount. They involve 

intricate procurement models, 

supply chain automation, 

engineering and planning 

collaboration. 

Business to Consumer (B2C) 

B2C relationships are very 

flexible. Buyers have full 

flexibility to change their 

suppliers. 

B2C relationships are usually 

one-sided, where businesses 

define and control the 

relationship with the consumer. 

Companies that have not yet put any resources into developing a 

comprehensive B2B strategy will most likely face immense pressure, 

sooner rather than later, either from customers, suppliers or competitors 

that have started reaping the cost benefits of doing business over the 

Internet. 

1.3.4. What is collaborative e-commerce? 

Collaborative e-commerce, also known as c-commerce, allows Internetenabled 

companies to share intellectual capital and leverage the core 

competencies of their trading partners. It promises to deliver significant 

increases in corporate innovation, productivity and profitability and 

create new opportunities for dynamic B2B collaboration over the Internet. 

According to the Gartner Group, by 2005 nearly half of all Web-based 

commerce will be collaborative in nature.


Collaborative e-commerce is enabled by B2B integration which leads 

to shared databases, open tracking systems, enhanced inter-enterprise 

visibility and cooperation, streamlined business processes, new cost 

efficiencies and an expanded customer base for every collaborative 

partner — all resulting in a competitive advantage that traditional 

business models simply cannot duplicate. 

1.4. B2B Integration (B2Bi) 

B2B integration or B2Bi is basically about the secured coordination of 

information among businesses and their information systems (see 

Figure 1.1). B2Bi provides a technology framework for B2B collaborative 

e-commerce. It promises to dramatically transform the way business is 

conducted between partners, suppliers and customers. All companies 

(i.e., large, medium, small and new) can experience increased growth 

and success through tightly integrated partnerships. 

Large Company 

Customer l> \^ Buyer 

t K Supplier 

tut mii 

Supplier customer 

**^JTO


Companies, from across a variety of industries, from consumer 

packaged goods, high technology, logistics and pharmaceuticals to 

chemical, manufacturing and financial services, are embracing B2Bi. 

They are realizing the enormous competitive advantage of B2Bi, through 

faster time to market, reduced cycle times and increased customer 

service. Through integration of business and technical processes, 

companies are able to strengthen relationships with service partners and 

customers, achieve seamless integration inside and outside the enterprise, 

gain real-time views of customer accounts, increase operational 

efficiencies and reduce costs. 

With B2B integration, collaborative e-commerce will truly come to 

life — moving from the phase of revolutionary idea to become a 

common aspect of business operations. The future e-commerce landscape 

is beginning to take shape. 

1.4.1. Integration: The top priority 

Business-to-business integration and enterprise application integration 

(EAI) are the top priorities of companies these days. B2Bi requires 

exchange of data and sharing of business processes across multiple 

trading partners, such as buyers, suppliers and distributors. EAI, on the 

other hand, requires internal applications, such as CRM, ERP and 

legacy systems, to interact with each other seamlessly (see Figure 1.2). 

B2Bi and EAI are accomplished by data, application and business 

process integration. The integration challenges in both B2Bi and EAI 

have a lot in common and can be overcome through a single, integrated 

solution. 

In a company today, resolving complex and costly integration 

issues is more critical than ever before. According to interviews of 

50 global firms conducted by Forrester Research, 77% of the interviewees 

(see Figure 1.3) recognized integration to be critically important for 

e-commerce strategy. Making application data available to trading partners 

and customers is also becoming increasingly important to the global 

companies. But less than one-quarter (24%) (see Figure 1.4) of the 

firms surveyed for the report have purchased software to enable businessto-business 

integration.

Portal 

Electronic 

storefront 


Relationship 

Management 

ERP 

Application 

Integration 

E-marketplaces 


Legacy Systems 

Suppliers &. 

Partners 

Collaborative 

Networks 

Figure 1.2. — B2Bi and EAI integrate all internal and external applications 

How important is application integration 

to your eGommerce efforts 7 

Extremely Important 

Totally irrelevant 

Don't Know 

Percent of 30 companies 

interviewed 

Source: Forrester Group 

52% 

6% 

Mow much does your company spend on integration ? 

fiitemat application 

42% 

28% 

10% 

6% 

&2H connections 

12% 

14% 


Have you purchased software Have you purchased software 

for internal integration ? for B2B integration ? 

No No 

38'% Yes 76% 

62% 

24% 

Percent of 50 companies Percent of 50 companies 

interviewed interviewed 

What was/is the biggest headache surrounding software integration? 

Source: Forrester Group 

Vendor problems 

in-' 

Dealing with 

Standards and legacy systems 

industry issue' 27% 

13% 

Problems with B^tt^" 

data formats ^^^^ Internal 

8% personnel 

issues 42% 

Percent of 50 companies interviewed 

Figure 1.4. — Most companies using a wait-and-watch approach for B2B 

integration 

cost associated with implementing a B2Bi solution may come down in 

the future. A typical B2Bi solution can cost a company any where from 

$350,000 to several millions of dollars. Additionally, some companies 

feel that they are not ready to make the highly difficult design choices 

that are fundamental to the dynamic nature of B2B application 

architectures, which have to react to rapid changes in commerce, market, 

technologies, standards and products. 

1.4.2. A daunting effort 

One of the key requirements of B2Bi is that, apart from the organization 

itself, its customers and trading partners have to participate in the 

integration process. In a hub-and-spoke type relationship, each trading 

partner has to integrate its applications, such as ERP, SCM and CRM 

with the corporate hub or marketplace at the center of the trading 

network.


B2Bi is easier said than done. Integration is a big challenge, especially 

for global corporations that have hundreds to thousands of trading 

partners. It is an extremely daunting effort to manage the integration of 

so many business processes and can turn out to be a time consuming, 

complex and expensive task. With the advent of new technologies, the 

potential of disparity further increases and makes the exchange of 

electronic information even more complicated. To resolve this problem, 

companies are forced to adopt one or more of the following strategies: 

• Limit e-commerce transactions to business partners using compatible 

systems. 

• Enforce proprietary formats on business partners. This is a typical 

strategy used in a hub-and-spoke type business relationship. 

• Stand on the side lines until B2Bi technology and standards are fully 

developed and used by companies in the same vertical industry. 

With the use of such strategies, several companies are not able to 

reap the benefits of B2B collaborative e-commerce. These are the 

companies that will have a hard time competing with more nimble 

companies that have a successful B2Bi implementation in the future. 

1.4.3. Getting beyond the starting line 

There are four main steps involved in building a successful B2Bi solution: 

• Plan a B2Bi strategy. The strategy should clearly state the different 

business processes that can be integrated with the business partners 

over the Internet, the benefits associated with the migration strategy 

and the technology and other resources required to achieve this 

transition. Evaluate and benchmark how other companies are 

successfully implementing B2Bi. Learn from their successes and 

failures. 

• Determine short-term and long-term integration goals: For a successful 

implementation, it is very important to identify both short-term and 

long-term integration goals. 

• Leverage existing systems. With B2Bi technology, companies can 

keep their existing internal systems while extending the information 

systems to accommodate e-business.


• Choose the right solution and solution provider. With the right B2Bi 

solution, a company can design architecture that provides easy, secured 

and reliable integration with trading partners ERP, CRM, legacy 

systems, portals and databases. 

The resulting architecture should represent existing business 

relationships and have the flexibility to build dynamic relationships. 

This architecture should lay down a roadmap for the required enterprise 

application integration along with B2Bi. It should also address Internet 

security and transaction management issues. 

Plan a B2Bi strategy 

As it is not possible to manufacture a product without clear instructions 

of its shape, color and functionality, in a similar way it is not possible 

to achieve an effective B2Bi without having a clear and visionary B2Bi 

strategy. The strategy should develop an integrated enterprise from 

customers to suppliers to distributors to B2B e-marketplaces to financial 

institutions. B2Bi involves fundamentally rethinking the business model 

to transform a company into a digitally networked enterprise — an endto-end 

integration of systems, data and applications. 

The B2Bi strategy should take into consideration the challenges 

imposed by the constant changes in the field of information technology. 

Apart from technology, the strategy should also give careful consideration 

to customer feedback, benchmark data, usage statistics, competitive 

analysis, current forces and current capabilities. 

Determine short-term and long-term integration goals 

After planning a strategy, the second step in moving towards an integrated 

enterprise goal is to examine a company's needs and the needs of 

partner companies with which it will be integrating. Basically, B2Bi 

strategy can be classified into two phases: the short- to mid-term 

plan (the next five years) and the long-term plan (the sixth year and 

beyond).

Short-term strategy 


In the first phase, a company should focus on how integration can 

reduce the operational costs, increase worker productivity, automate 

supply chain and improve customer relationships. The implementation 

of the technology will likely affect almost every aspect of a company's 

business, for example, customer relationship management (CRM) 

packages will automate the sales and support process. Apart from 

providing a real-time, personalized service to the customers, supply 

chain management (SCM) systems, B2B e-marketplaces and collaborative 

networks will change procurement, inventory control, order management 

and tracking processes. It is strategically important for a company to 

determine the following with respect to its trading partners (i.e., buyers, 

suppliers and distributors): 

• Have its trading partners implemented any B2Bi solution? 

• Will they interact with it through existing networks or legacy systems? 

• Can they interact with it through various B2B e-commerce channels 

such as B2B e-marketplaces? 

• Which elements (such as order management, procurement and catalog 

management) of the B2B relationship need integration? 

Identifying integration goals is not a single step task. It takes several 

iterations in architectural design, assessment of internal and external 

systems and constant evaluation of processes to formalize them. A 

company has to constantly evaluate factors such as industry standards, 

standards being used by the B2B e-marketplaces in which it is 

participating and participation in new collaborative networks in its 

vertical industry. 

Long-term strategy 

The second phase of a company's B2Bi strategy is the long-term plan 

(the sixth year and beyond), which involves envisioning and understanding 

the company's long-term goals. B2Bi is an asset that can 

create sustained business value. It is important to look beyond immediate 

B2Bi needs to obtain this sustained business value.


Companies can use a scenario methodology for long-term planning. 

In scenario methodology, a company has to imagine a number of 

possible scenarios, positive and negative, that could evolve in its industry, 

business relationships and technological advancements. Based on these 

scenarios and the sequence of events leading to them, a company will 

have to predict if it is technologically prepared for them. This evaluation 

can be a very iterative process, but would allow a company to reposition 

its technology direction in time. With the use of this methodology for 

long-term planning, B2Bi goals would be a continuously evolving process. 

The factors that should be considered in scenario methodology 

include: situational analysis, technology validation, financial planning 

and organizational development planning. 

Other factors that a company has to constantly consider are: 

• How might its B2B relationships evolve in the future? 

• What new types of business partners (suppliers, channels) might it 

have in the future? 

• Does the B2Bi infrastructure provide secure, location-independent 

access points to applications, a necessity for today's mobile workforce 

and extended corporation? 

• Has it taken a holistic approach to e-business networking that provides 

an infrastructure for an entire e-business enterprise: internal operations, 

business partners and customers? 

The e-business integration goals should serve as a roadmap to ensure 

that the organization uses its technology and business to realize its full 

potential. 

Leveraging existing systems 

B2Bi technology will have a significant impact on business computing 

and is integral to moving enterprises towards integrated infrastructures. 

The B2Bi model substantially changes the way corporations plan, design, 

build, deploy and manage future business applications. The success of 

this evolution for any company would be determined by these two 

critical factors: how well it has leveraged existing investments in 

corporate infrastructure and how well it has ensured flexibility for the


future. Companies that architect their B2Bi implementation strategy 

based on these two factors and choose a solution that meets these 

requirements, without compromising security, scalability and performance 

will be the winners in long run. 

Companies charging towards B2B integration have a lot to learn 

from the old adage "make new friends, but keep the old". This old 

maxim is very pertinent in today's dynamic technology and business 

environment. Although it is important for the companies to embrace 

new technology like B2B integration, they still have to retain and 

effectively use their legacy systems. Over the years, companies have 

invested several million dollars in building, maintaining and enhancing 

these core systems which have been supporting the business for decades. 

It would be absolutely imprudent to throw away these systems and 

start everything from scratch. With the right transition methodology, 

implementation tools and smart vision, companies can effectively leverage 

their legacy systems, implement new integrated e-business solutions and 

tie them all together. 

Legacy extension enables a corporation to use pre-existing applications, 

like mainframe systems, that contain all the data, business rules 

and logic and extend their functionality to other applications such as 

ERP, CRM and B2B type applications. The new B2B applications can 

build on the proven business logic and processes by just acting like 

wrappers to the data contained within the legacy systems. In fact, 

legacy extension systems encapsulate the existing business processes. 

With this extension, organizations can reduce the overall B2Bi 

implementation cost, time and effort. 

1.4.4. Selecting the right B2Bi solution 

B2Bi is much more than just planning a strategy and getting applications 

to communicate with each other. Without the right tools and the right 

solution, any integration implementation will be doomed. Before a 

company selects any solution or solution provider and pools all its 

resources into it, it should consider the following: 

• Can the solution evolve with the company, with the industry and with 

the IT industry?


• Does it offer comprehensive functionality with the flexibility to 

support third-party software vendors and connect existing and new 

systems in a common framework? 

• Does it work within scalable environments to accommodate customer 

and trading partner systems as well? 

• Does it support open standards? 

So, what are the key features that a company should look for before 

investing in any B2Bi software package? 

Any transaction, any time — end-to-end, partner-to-partner 

A B2Bi solution should be able to link a company to buyers, sellers, 

e-marketplaces and collaborative networks automatically in real-time. It 

should be able to: 

• Fully automate real-time exchange of data between disparate 

applications; 

• Integrate customer relationship management, procurement, supply chain 

management, databases and other legacy applications, regardless of 

existing technology at either end; 

• Provide easy bi-directional connectivity to collaborative networks; 

• Easily populate the existing enterprise information systems with the 

data resulting from B2B business process communications like 

purchase order, request for quotation and order status at both ends; 

• Provide easy integration for dynamic content like catalogs and 

inventory from the enterprise's systems into each portal's proprietary 

system; 

• Be flexible enough to extend B2Bi links to any trading partner and 

any B2B exchange as long as they adhere to industry standards for 

business process communication; 

• Enable sharing transaction-based business information with buy-side, 

sell-side and third party portals and exchanges; 

• Provide business objects that are a one-to-one mapping of the most 

common business processes; 

• Provide graphical flow control language for easy integration with 

business systems;


• Ensure the security, integrity and privacy of each transaction through 

security features such as encryption and authentication; and 

• Provide clustering solutions for load balancing along with robust fail 

over capabilities. 

Conduct all transactions securely 

The B2Bi solution should address all types of electronic transactions 

including, but not limited to: 

• Catalog management transactions such as price/sales catalog, product 

descriptions, product change notification and inventory availability; 

• Order management transactions such as quote and order entry, 

transportation and distribution, returns and finance and product 

distribution; 

• Supply chain management transactions such as purchase orders, 

collaborative forecasting, inventory allocation and replenishment, 

inventory reporting and sales reporting; 

• Financial transactions such as payment orders, remittance advice, 

invoices and consolidated invoices; and 

• Logistics transactions such as motor carrier bills of loading, logistics 

service requests and responses and shipment status inquiries. 

Flexible 

The B2Bi solution that a company chooses should support diverse sets 

of file formats, protocols, telecommunications and security standards. A 

company should be able to make a single connection to its B2B 

integrator and let it take care of all the complex, behind-the-scenes 

work necessary to bridge the electronic gap between its partners, vendors 

and customers quickly and painlessly. 

The solution should be based on open standards that allow the 

company and its partners to send transactions using any combination of 

the following (see Figure 1.5): 

• Applications and file formats (SAP, PeopleSoft, Oracle and ANSI 

X.12, XML, etc.); 

• Telecommunications pathway (Internet, VAN, Frame Relay, etc.);


E-marketplace 

Ail File Formats 

AN Communication Protocols 

AM Security Solutions 

AM B2B Standards 

Logistics Provider 

Figure 1.5. — A typical B2B integration solution 

in mi 

• Communication protocol (FTP, HTTP, HTTP/S, etc.); 

• Security (digital certificates, Secure Socket Layer, PGP, PKI, etc.); 

• Service requirements (archiving options, routing, monitoring, etc.); 

and 

• B2B protocols and standards, including OBI, RosettaNet, OAG, 

BizTalk and ebXML. 

1.5. What is the Return on Investment (ROI) 

on B2Bi? 

Through B2Bi, the integrated companies operate efficiently on a realtime 

basis, which has a direct impact on their bottom line. The return 

on investment for B2Bi is extremely high — often 5 to 15 times more,


with a payback period measured in months, not years. The ROI on 

B2Bi comes from the increased operational efficiency and reduced costs 

that are achieved by streamlining, automating business processes, reduced 

cycle time and supply chain automation. 

How do you measure the ROI on B2Bi? Well, there is a right way 

and a wrong way to measure ROI. The wrong way to justify B2B 

integration is by measuring the time representatives save in reduced 

paper work, or in revenue the company saves by slicing the need for 

data entry. The right way is to measure the quantum of reduction in 

operational and developmental costs. 

B2Bi represents opportunities to increase revenues through decreased 

communication, reduction in operational and development costs and 

automated supply chain and customer relationship management, resulting 

in higher profit margins. It dramatically reduces human intervention in 

business processes for faster, more reliable and more profitable 

transactions. The benefits of B2Bi, lower costs, reduced inventory 

levels, faster time to market and better-informed decisions, have a 

cumulative effect on increasing the productivity of a company. In a 

recent research report, BCG forecasts that, by 2004, business-to-business 

integration will generate productivity gains equivalent to 1-2% of sales; 

by 2010, this figure could grow to 6%, or roughly $1 trillion. 

Increased Revenue + Decreased Cost + Improved Efficiency = 

Higher Profitability 

A company should calculate the implementation and ongoing costs 

associated with the project including software, hardware, system 

integration and future production support expenses. These cost estimates 

should be carefully examined to determine the return on investment 

(ROI) for the proposed solution. Every company wants to be considered 

forward thinking, but revenue, not technology, is still the king in the 

corporate world. Beware of any overly ambitious initiative spearheaded 

by the IT department. 

Though many software vendors claim an out-of-the-box solution to 

B2B integration, the truth is that implementing a B2Bi solution can 

often be a laborious, expensive undertaking.


ADAPTEC ACHIEVES AN ROI OF 1500% THROUGH B2Bi 

Adaptec is a $1 billion global manufacturer and supplier of network 

and I/O connectivity hardware and software products such as board, 

chips and software to some of the biggest computer vendors — IBM, 

HP, Compaq, Sun and Dell. It competes in an environment of shrinking 

product lifecycles, increasing customer demands and decreasing 

margins. To remain competitive, the company had to reduce its 

supplier lead-times and reduce overall cycle times from 105 days to 

55 days. 

Unlike many competitors, Adaptec does not have its own fabrication 

and assembly facilities and has the additional challenge of coordinating 

the production of its IC products through several contract-manufacturing 

partners in Asia. Board-level assembly and final testing is 

conducted at their own high volume manufacturing facility in 

Singapore. This process requires tight integration among all the 

partners in the back-end of the supply chain. 

This manufacturing approach removes the need to invest 

$1.2 billion in its own fabrication facility, but increases the need to 

interact seamlessly with Asian partners. Adaptec's previous methods 

of communication — fax, e-mail, FTP and EDI — had inherent 

problems that caused delays and increased lead-times, making it less 

competitive in the market. 

Extricity Alliance, a B2Bi solution, enabled Adaptec to connect to 

its external business partners securely and in real-time over the 

Internet, streamlined interaction with its global manufacturing partners 

and facilitated the exchange of information and transactions. The 

way Extricity Alliance connected business partners was highly flexible, 

which made it easy to support information exchanges and changing 

business processes. 

Extricity Alliance has enabled Adaptec to create a 'virtual factory' 

by integrating the back-end of supply chain and automating a wide 

range of shared business processes — collaborative engineering, WIP 

updates and forecast sharing. The solution has helped to cut manufacturing 

cycle times by up to 50%, reduce inventory by 25% and 

Continue on page 23


Continued from page 22 

greatly improve customer satisfaction — resulting in a significant 

competitive edge for Adaptec and bottom-line savings of $2 million 

per year. The solution is estimated to have an ROI of 1,500%. Other 

benefits include improved on-time delivery due to better supply chain 

coordination and increased visibility to manufacturing processes. 

Taking four weeks off the cycle time resulted in a one-off $9 million 

saving for the company. 

Source: Condensed from Extricity Software, Solution for Adaptec, EAI Journal 


B2B integration is the pervasive enabler of most current business 

strategies such as collaborative e-commerce, collaborative networks, 

supply chain management (SCM) and customer relationship management 

(CRM) across multiple channels of delivery including wireless devices 

and the Internet. 

B2Bi strategy should be laid out and executed in such a way so as 

to: have an integrated, real-time application-to-application, system-tosystem 

interaction with all the existing and new trading partners; 

eliminate all manual steps in business processes; conduct secure and 

real-time commerce transactions over the Internet; have the flexibility 

to accommodate the different mode of interactions of each partner; and, 

finally, have the ability to adapt to change quickly and easily in this 

dynamic age of B2B collaborative e-commerce. This is what B2Bi is all 

about — the end-to-end automation and integration of cross-organization 

business processes, data, applications and systems.

Chapter 2 

Components, Benefits, 

Challenges and Applications 

of B2B Integration 


There are multiple components of B2Bi and each one of them has 

its own importance in planning a company's B2Bi strategy and 

implementation. 

In this chapter, we will reveal all the major components of B2Bi, 

B2Bi benefits and potential challenges that a company may face in its 

implementation. We will also introduce some of the most important 

B2Bi-enabled applications such as supply chain management, 

e-marketplaces and collaborative networks. 

24

Components, Benefits, Challenges and Applications of B2B Integration 25 

2.1. The Word is Out 

The word is out: dynamic business collaboration on the Internet is a 

strategic imperative. There is a great hustle and bustle going on in 

IT and business divisions of all companies either to kick start or, 

having done so, to quickly finish the integration process that provides a 

seamless, end-to-end solution for integrating customers, partners and 

suppliers. 

In this chapter, we will discuss all the major components of B2Bi, 

the bottom line benefits of B2Bi to companies and the challenges that 

they may face in B2Bi implementation. This is followed by an 

introduction to a few major applications enabled by B2Bi, such as 

supply chain management (SCM), B2B exchanges and collaborative 

networks. 

2.2. B2Bi Components 

B2Bi consists of multiple components, each one being of different 

priority for different companies. It may not be possible to incorporate 

all the components in the first phase of B2Bi implementation; however, 

it is prudent to at least include them in long-term B2Bi goals. 

2.2.1. Integration patterns 

Companies can achieve B2Bi using one or more of the following 

integration patterns (see Figure 2.1): 

• Data oriented integration; 

• Application oriented integration; 

• Portal oriented integration; and 

• Business process oriented integration. 

Most of the companies have to use a combination of these patterns 

to achieve integration with their trading partners. The choice of the 

integration pattern is based on several factors, including the nature of 

integration agreement with the trading partners, degree of synchronization 

required, budget, short-term and long-term business goals.


L_; Hi Hi 

Portal Oriented Integration 

m 

Application Oriented Integration 

D 

Data Oriented Integration 

Business Process Oriented Integration 

Figure 2.1. — B2B integration patterns 

2.2.2. Enterprise Application Integration (EAI) 

The initial part of a B2Bi solution includes linking diverse applications 

installed within the enterprise. This is known as enterprise application 

integration (EAI) and it involves all the legacy systems running the 

business, ERP packages, CRM systems and internal applications (see 

Figure 2.2). From a technological point of view, it involves a complex 

mix of databases, multiple operating systems and several protocols. 

According to recent research, 65% of the organizations that are 

deploying B2B e-business systems are not tackling the internal integration 

issues. It is really unfortunate that the B2Bi strategy in most of these 

companies will fail drastically, as they will have the train but would 

not have laid the track, so to speak. For these companies, the internal 

applications would largely remain fragmented. 

To evolve from the brick and mortar format, companies will have to 

first go through the painful process of integrating existing disparate 

systems.


Messaging 

Middleware 

Application ptppiicauuu 

A ^~ 

packages *cP' .*- 

Databases 

(ERP,CRM..) \& «rf*»\V 

.irfk j j.**"* . - Internal Business — - 

A^ 

j ** Processes 

^"-^•"* Legacy Systems 

Database 

Interfaces 

Figure 2.2. — Enterprise Application Integration components 

2.2.3. Business Process Management (BPM) 

B2Bi is as much about business process management as it is about 

technology. B2Bi implementation provides every corporation with the 

opportunity to redefine and automate core business processes, which 

results in streamlined business operations and reduced cost. 

BPM for B2Bi is focused on how business partners can refine their 

business processes so that the applications supporting them can be 

seamlessly integrated. With effective BPM, companies can become a 

part of a unified business process flow and unified supply chain. 

Unified workflows allow the dynamic sharing of state information 

among trading partners, through which all communication can be tracked 

and recorded. Since B2B transactions can span over multiple days, 

unified workflows become critical in ensuring the completion of 

automated business transactions. 

2.2.4. Extensible Markup Language (XML) 

XML (Extensible Markup Language) is a technology based on open 

standards that standardizes and simplifies the communication of business


processes among companies. All life forms are carbon based. All 

e-business applications will be XML based. 

XML provides an open platform for businesses to communicate 

over the Internet, enabling dynamic 'anywhere-to-anywhere' business 

interactions. It is the universal language that makes structured Web 

data meaningful and enables computers to recognize easily and to 

exchange contents and business documents, such as purchase orders, 

catalog inventory and invoices. XML is self-describing and provides an 

efficient means to separate the data and structure in electronic business 

documents from processes. With the use of XML in B2B applications 

(see Figure 2.3), trading partners do not have to go through the 

cumbersome process of mapping one another's business processes into 

Users 

Buyer Buyer Supplier Supplier 

Tl II II 

Internet 

Buyer «L^ Supplier 

cXMLl 

Internet f> 

cXML ~ 

- Internet 

E-marketplace 

J Internet 

XML 

4 E-marketplace 


Figure 2.3. — Example of use of XML in B2B applications 

Di liihulfiis 

DisliibuLuis 

Distributors


complex EDI-based messages. This completely changes the dynamics of 

communication in B2B applications. 

For a successful B2Bi implementation, the companies will have to 

reengineer their business processes to be XML-centric. Their new 

infrastructure must support critical XML standards, enable transformations 

and provide links to legacy applications. 

2.2.5. XML standards for e-business 

Just as the explosive growth in the usage of Internet was made possible 

by the standardization of the Web browser, the adoption, growth and 

success in B2B e-commerce will be controlled by the standardization of 

XML communication representing business processes among trading 

partners. There has to be a common set of business processes and a 

common grammar for B2Bi to work. 

In B2Bi, interoperability issues exist at almost every level — catalog 

management, order management, collaboration tools, EDI protocols, 

shipping services, etc. Standards for data exchange for all the business 

processes involved in B2Bi help in overcoming the interoperability 

issues. 

Several industry organizations, such as RosettaNet, are defining their 

market-segment-specific definitions. 


Web services are Internet-based, self-describing and self-contained 

software resources that form the building blocks of distributed applications 

and business processes spanning across multiple organizations. 

Web services offer complete interoperability as they are based on 

open messaging standards. They work in conjunction with other Web 

services to complete part of a complex work-flow or business transaction. 

Web services can be invoked by partner applications at run-time, 

over the Internet. The client applications may not even have any prior 

knowledge of their existence. In essence, Web services enable just-intime 

B2B application integration.


2.2.7. Middleware technologies 

Middleware is a layer of software between the client and server 

applications that provides a uniform 'conduit' for them to communicate 

with one another. Middleware provides a platform for the integration of 

applications (developed in different programming languages and installed 

on different operating systems) and data sources (provided by different 

vendors). Middleware can be classified into different categories that 

include: transaction oriented middleware, message oriented middleware 

(MOM), distributed objects and components-based application servers 

and communications middleware. 

2.2.8. Integration brokers 

Integration brokers built on top of messaging middleware, known as 

message brokers, provide intelligent translation and routing of messages 

from the source to the target application. They enable content-based, 

sequential and conditional routing of messages. They also provide a 

message warehouse or repository for storing raw, unprocessed messages 

for archiving and retrieval. 

Companies will be able to achieve faster and reliable B2Bi with 

integration brokers than with any other middleware solution. 

Integration brokers provide adapters for application servers, packaged 

applications such as CRM applications and SCM applications, legacy 

applications and databases (see Figure 2.4). They support all open 

standards and enable communication irrespective of the transportation 

protocol. Integration brokers also impose a structure on the integration 

development process, thereby reducing the cost of maintaining application 

integration solutions. 

Integration brokers are the middleware of extranets that link 

applications and transactions not just across the enterprise but also 

across business-to-business networks. 

2.2.9. Internet security 

In B2Bi, companies connect their internal systems to the Internet and 

through that single pipe they can potentially lose everything. A B2B


/Constr- SQL 

Business Rules 

Formulas Actions Conversion /' 

/ Name Value Fixed Length \ 

/ I 1 \ 

[ Message Transformation 1j 

\ Object Streams Variable 

/Rosetta- \ 

/ Net EDI ebXML BizTalk', 

Standards 

\ Swift CXML OASIS X12 / 

\ / 


Broker 

/ CRM Internal Accounting 

Applications 

ERP SCM Legacy Financial / 

/ Sybase MS-Access InformixX 

i i \ 

Databases 11 

\ Oracle SQL Server Db2 

\ 

Figure 2.4. — Integration broker connectivity 

transaction usually involves sharing proprietary information, electronic 

exchange of huge assets and potential involvement of multiple partners. 

It would be disastrous for a company to ignore the security requirements 

before participating in such transactions. 

B2Bi infrastructure requires a cohesive security and network 

infrastructure through which the enterprises (buyers, suppliers and 

distributors), B2B exchanges and service providers are able to manage 

securely complex relationships with both users and partners. 

2.2.10. Wireless technologies 

According to the Gartner group, more than 108 million employees 

worldwide will regularly work outside a traditional office. Companies 

/


are facing the challenge to provide these employees with access to 

corporate computing resources. The access cannot be limited to basic 

features, such as e-mails, but needs to be a complete hookup into 

applications that enable them to be productive anytime, anywhere. 

Companies have to design and implement solutions that extend Internet, 

intranet and extranet applications wirelessly to handheld devices, based 

on the Palm and Windows CE platforms, as well as Internet-enabled 

phones. 

Integration of these mobile devices with a company's internal and 

trading partners' applications is now becoming an integral part of 

B2Bi. 

2.2.11. Software agents 

The B2B e-commerce environment is both information and process 

rich. In the current environment, there are a lot of manual processes, 

such as information gathering and catalog management. Agent technology 

is very relevant in such an environment, as it is useful where a 

personalized, continuously running semi-autonomous behavior is desired. 

Most of the work of information gathering and process management 

tasks can be delegated to agents. 

However, decisions in which the agent can possibly make a suboptimal 

choice, such as which stock to buy and approving a big 

contract, cannot be left to the software agent as the consequences of 

missed opportunities or unfavorable decisions can be severe. 

2.3. Benefits of B2B Integration 

Following are several tangible and intangible benefits of B2Bi, which 

directly affect a company's bottom line: 

2.3.1. Dynamic business relationships 

B2B integration enables dynamic business relationships and processes 

that respond flexibly and quickly to new business models and changing


customer demands. B2Bi makes it faster, easier and safer for companies 

to bring into their ambit new associates and automate cross-enterprise 

business processes with them. Only a tightly integrated and highly 

automated organization can have this level of flexibility and adaptability 

to newer partners. 

2.3.2. Real-time information 

B2Bi enables the secured exchange of real-time partner-specific and 

task-specific business information over the Internet, which has unlimited 

benefits. It gives companies the 'power of now'. 

As an example, let us assume that a company has seamlessly 

integrated its logistics system with all of its major shipping vendors. 

With this integration, the company will have a consolidated real-time 

view of shipments from multiple vendors. Even the company's direct 

customers can securely access up-to-the-second shipping information 

through its corporate Website or via direct B2B links. 

2.3.3. Lower transaction costs 

Through B2Bi, companies reduce not only the B2B transaction costs 

but also the complexity associated with them, while maintaining complete 

business logic. 

We are not talking about some small savings here. By exchanging 

business transactions electronically, companies can save as much as 

80% of the costs associated with conducting these same transactions 

on paper. 

According to a recent report from Goldman Sachs, Ford and GM, 

companies predict a savings of up to 20% from their Internet-based 

supply chain management systems. Likewise, British Telecom expects a 

90% per transaction cost savings from its B2Bi efforts. 

The report also stated that currently less than 0.5% of all intercompany 

transactions take place electronically. By 2004, this number is 

expected to be more than 10% driven by the cost savings associated 

with e-commerce.


2.3.4. Participation in online marketplaces 

What is the advantage of participating in an online business community? 

Consider the data provided by Grainger's consulting unit on the 

advantages of electronic marketplace sales: 

• Cuts transaction costs by 32%; 

• Reduces inventory and production costs by 25%; and 

• Slashes errors and exceptions by 52%. 

B2Bi allows companies to build digital marketplaces or participate 

in multiple vertical and horizontal markets. 

2.3.5. Streamline business operations 

B2Bi helps companies to automate, reshape and improve the efficiency 

of their business processes via business process management. It automates 

the inter-organizational, inter-functional and inter-personal activities of 

these processes. 

2.3.6. XML-based integration 

B2Bi over the Internet is completely credited to the use of XML, which 

fully leverages the open standards of the Internet. 

Today, companies are faced with the daunting challenge of linking 

inter-company data and processes for their business-to-business (B2B) 

e-commerce initiatives — all while integrating customer and packaged 

applications, databases and mainframe systems within the enterprise. 

How are the companies addressing these challenges? The answer is by 

using XML-based B2B integration. 

2.3.7. Increased customer service and retention 

With real-time and quality information companies get an opportunity to 

provide much better personalized service and upgraded value-added 

services to valuable customers. Through B2Bi, there is complete transparency 

of business information end to end, which empowers customers 

to make better decisions and let companies respond to customers' needs


swiftly, helping customer retention. B2Bi is the evolution of how close 

a company can get to its customers. 

For example, General Motors Corp. is working with Reynolds and 

Reynolds to deploy online software that will help the world's largest 

automaker integrate its supply-chain systems with the inventory 

management systems of GM's 8,000 North American dealers. 

The primary goal of the $150 million-a-year alliance is to give 

consumers a seamless brand experience, whether they walk through 

the door of a dealer or click on a mouse. The software will link GM 

and its dealers as well as support the automaker's current BuyPower 

consumer Web service. The software is designed to make it easier for 

all involved to share information. Consumers will be able to track the 

status of their vehicle orders like FedEx customers track packages. GM 

dealers, for example, will gain access to the service history of a specific 

customer's vehicle. 

2.3.8. Opportunity to re-architect internal systems 

Companies seeking B2Bi quickly face the poor architecture of many 

core business systems and current infrastructure, which hardly provide 

an adequate base for an integrated future. B2Bi presents a tremendous 

opportunity to companies to clear up the mess within their organization. 

The properly designed architecture and infrastructure, which fully 

leverage the existing systems, will be able to conduct secure, nonrepudiated 

transactions in real-time, be designed to sustain competitive 

advantages and be flexible enough to adapt quickly to new technologies 

and business demands. 

2.4. B2Bi Challenges 

Business process and application integration, both between and within 

enterprises, is a lot more complex than companies think. Companies 

tend to underestimate the complexity of B2Bi, technically and from a 

business value proposition. All of the major 15-20 domains of B2Bi, 

such as customer relationship management, supply chain management, 

operations management and planning have multiple (4-5) sub-domains.


Each of these sub-domains is supported by multiple applications. The 

core of the problem is that even applications supporting a sub-domain, 

for example catalog management within the supply chain, are not 

designed in such a way that they can exchange data with one another. 

They do not have a common data architecture, nor do they have a 

common messaging format. It is like a cartesian product of problems. 

A word of advice: do not let these challenges deter you from moving 

towards an integrated enterprise. In this book, we will discuss not only 

the challenges but also the remedial solutions and how to work around 

them. 

Let's review in detail all the major challenges that the enterprises 

face in achieving the goals of B2Bi. 

2.4.1. Internal application integration 

One of the biggest challenges companies face in B2Bi is integrating 

information among existing internal business applications. According to 

EAI Journal, an average Fortune 500 company may have 50 or more 

internal business applications. Very few of these applications are truly 

integrated with each other. 

A typical business process involved in B2B e-commerce is completed 

by multiple application systems. So, when a company buys a new 

application, it has to build an interface between the new software and 

many, if not all, of its existing applications. It is an extremely resource 

intensive, time consuming, expensive and a complex process to design, 

develop and maintain so many diverse interfaces. 

Thus, the first challenge that the companies face in their 

implementation plan of B2Bi is the fact that the internal applications 

must be integrated. In fact, in a B2Bi project, most integration dollars 

are spent on internal integration projects. 

According to Forrester Research, which conducted a survey on EAI 

at several companies, the following factors (in order of their importance) 

make integration difficult (see Figure 2.5): 

• Internal personnel issues; 

• The diversity of the applications in the legacy systems that must be 

linked;

• 


Have you purchased software Have you purchased software 

for internal integration ? for B2B integration ? 

No No 

38% Yes 76% J= S 

62% 

24% 

Percent of 50 companies Percent of 50 companies 

interviewed interviewed 

What was/is the biggest headache surrounding software integration? 

Vendor problems 

10% 

Dealing with 

Standards and |egacy systems 

industry issues 27% 

13% 

Problems with •HM'*' 

data formats 1^^ Internal 

8% personnel 

issues 42% 

Percent of 50 companies interviewed 

Figure 2.5. — Factors that make integration difficult 

Standards and industry issues; 

A bewildering array of application integration options provided by 

different vendors to choose from; and 

Data format problems. 

The survey also found that out of 50 global companies, 62% purchased 

software tools to hook together internal applications. 

2.4.2. Disparate internal corporate data 

Internal data integration is the single most expensive problem to fix. 

The internal application integration issue becomes pretty complex for 

companies that have application data scattered across several different 

databases. For example, a large financial services institution may offer 

several products — brokerage, mutual funds, insurance, credit cards and 

savings accounts — but each product may be managed by its own 

legacy accounting system. There is no easy way to link all of these 

accounts together to let a customer see his or her entire portfolio of 

products without having to be authenticated for each account.


2.4.3. System heterogeneity 

B2Bi poses a double pronged problem — internal systems heterogeneity 

and external systems heterogeneity. A global 2000 company has 

thousands of employees and several hundred business partners. Its IT 

infrastructure is comprised of multiple applications (commercial and 

in-house), running on several different operating systems, networks and 

hardware. This is a problem compounded by the fact that each partner 

(supplier, distributor and customer) has a different IT infrastructure. 

The technologies to integrate such a heterogeneous (in terms of 

software, hardware, operating systems and programming environments) 

and distributed system are very complex and difficult to put in place. 

As the number of companies participating in the B2Bi process grows, 

the complexity of the integration challenges increases exponentially. 

2.4.4. Data security 

Companies struggle to find a complete B2Bi solution that would link 

internal systems with partners' systems quickly, bringing guaranteed 

delivery, secure communications and transaction traceability over the 

Internet. 

B2B transactions involve high value, sensitive corporate data and 

exposure of internal back-end systems. There is a lot at stake, hence the 

issue of security is extremely important. 

2.4.5. Transaction integrity 

Transaction integrity is defined as the degree to which a transaction 

flowing through a network reaches its intended destination without 

impairment of its function, content or meaning. 

To leverage maximum value from B2Bi, it is critical to ensure that 

each business process between applications completed successfully — 

from the point where the transaction is initiated all the way through to 

every application where the information is being used. If the transaction 

fails at any point, the whole transaction has to be aborted. Since B2B 

applications are distributed, it is a major challenge to maintain 

transactional integrity.


2.4.6. Internal business process management 

B2Bi cannot be achieved through the traditional thinking of the 

companies, which treats any integration issue as a technical issue that 

can be addressed with technical solutions. This approach ignores the 

root cause of the integration challenge — the lack of business process 

integration that the technology infrastructure supports. The main objective 

of BPM is to make business processes effective, efficient and flexible. 

A global 2000 company is typically crippled with redundant business 

units, performing redundant processes and using redundant data structures 

and systems. For example, they may have up to 12-15 different billing 

applications that replicate a majority of the business processes and 

about 95% of the billing data. The billing data for each such application 

usually resides in a separate database and is not accessible to other 

applications. The root cause of these redundancies is bad design of 

business processes and the redundant business units that use them. 

Integration of all such systems requires major business process 

reengineering, which is obviously met with severe resistance from 

employees. 

2.4.7. Inter-enterprise business process integration 

B2Bi requires integration of inter-enterprise business processes. To 

achieve this, teams of business-unit and IT professionals from the 

trading partners have to get together regularly and redesign core business 

processes from a business-to-business integration perspective. 

Business process oriented integration happens at multiple levels, 

across multiple organizational units and it is an extremely daunting task 

to coordinate it. Several complex business processes such as materials 

planning and forecasting are not easily integrated among the trading 

partners. 

2.4.8. Internal resistance 

Even if the B2Bi implementation team can guarantee the integration of 

legacy systems, heterogeneous cross-organization applications and 

business processes, there is no guarantee that B2Bi implementation will


be successful. For the successful implementation of B2Bi, all the business 

departments of a company have to work hand-in-hand with the technology 

department. The whole company has to be mobilized and all departments 

(sales, marketing, distribution, purchasing) have to adopt new business 

models and that is hard stuff. 

2.4.9. Standards and industry issues 

The lack of industry standards for conducting business-to-business 

transactions over the Internet is a major deterrent to implementing B2Bi 

for many companies. 

The main challenge in using XML is not with document structure 

and syntax, but with the semantics of the document which represents a 

business process. Several companies and industry groups have proposed 

a variety of different XML extensions and protocols. No one knows 

which standards will survive in the long run. 

2.4.10. Distributed control 

B2Bi involves interaction and congruence among multiple IT groups, 

multiple business user communities and multiple groups of decisionmakers. 

Each group has an independent set of goals and requirements. 

Anything that involves high levels of agreement or the intertwining of 

systems and people is difficult to achieve and even more difficult to 

maintain. With the increase in the number of partners that a company 

wants to integrate with, the problems associated with distributed control 

take precedence over all other problems. 

2.4.11. Performance and scalability 

B2Bi requires real-time aggregation or distribution of information across 

dozens or hundreds of companies. Such a type of distributed architecture, 

if not properly designed, can significantly hurt the performance of 

applications. Delays of only a few seconds in B2B transactions can 

result in significant losses to trading partners. This can potentially 

result in disappointed customers and damaged working relationships.


2.4.12. Expensive 

B2Bi implementation is an expensive process. The most basic B2Bi 

solution, together with the expense of customization, can cost upwards 

of $1.5 million. A substantial amount of money is also spent in EAI 

activities such as data cleansing, legacy-system and internal business 

process integration, which are prerequisites to B2Bi. 

Forrester Research puts developmental costs at $1.5 million for a 

basic B2B site to more than $15 million for the most sophisticated 

sites, another $700,000 a year to keep up a basic site and up to $4 

million a year to run a high-end site. 

2.4.13. 24/7 availability of the system 

24/7 availability of real-time data in B2B applications, which is one of 

the key advantages of B2Bi, is also one of its biggest challenges. In 

most companies, the data is exchanged and loaded through nightly 

batch processes. However, the logical expectation with B2Bi is that the 

data is always available and can be accessed over the Internet. Companies 

can work around a data availability problem through data replication, 

but it is an expensive process. They have to make the business decision 

as to whether it is worth the expense of replicating data on a real-time 

basis, an hourly basis or through nightly batch cycles. 

2.5. B2Bi-Enabled Applications 

The array of potential B2Bi-enabled applications is vast and varies from 

industry to industry. In this book, we will be thoroughly discussing two 

critical B2Bi-enabled applications: supply chain management and B2B 

exchanges and collaborative networks, which are common to most 

industries. 

2.5.1. Supply Chain Management (SCM) 

Supply chain automation, which builds dynamic communities connecting 

the enterprise with customers and suppliers, is one of the best B2Bienabled 

applications. B2Bi uses Web-enabled technologies to join the


Browse Products and 

Place Order y 

Check Credit 

History 

Buyer E-procurement 

Response 

Check Order S,te Purchase 

Status 

Order 

Statement 

of Bill 

Deliver Products 

linn rn 

Bank 

Bill of Shipment 

Supplier 

Ship 

Products 

Figure 2.6. — E-procurement in an integrated supply chain 

Shipper 

different 'links' in the supply chain — such as manufacturers, material 

vendors and retailers (see Figure 2.6). This transforms the traditional 

supply chain into a supply community. Such a supply chain community, 

integrated with collaborative technologies, results in a shared value 

chain that delivers reduced operational costs, lower inventories, increased 

efficiency and greater customer satisfaction. 

2.5.2. E-marketplaces and collaborative networks 

B2B e-commerce can be transacted either directly between business 

partners or through an intermediary known as an exchange or an 

e-marketplace (see Figure 2.7). E-marketplaces allow all businesses 

including suppliers, buyers, financial institutions and shippers, irrespective 

of size and location, to collaborate in a real-time basis over the Internet. 

By participating in B2B e-marketplaces, the companies have the ability 

to negotiate better pricing, reduce transaction costs and reach a broader 

range of customers or suppliers.


Sel lers 

Sellers 

Distributors 

Suppliers 

Manufacturers 

A Typical E-marketplace Buyers 

i M Collaboration **• ' Buyers 

l 1 Trading Events ~ ^ | 

*t SpotPurERisi—1 [» Resellers 

1 J Shared Wbrfflow/ 

O. T Process Matching 


Part II 

Established Integration 

Components 

45


Chapter 3 

Integration Patterns 


To achieve B2B integration, a company will have to adopt one or more 

of the following integration patterns: data oriented integration, portal 

oriented integration, application oriented integration and business process 

oriented integration. Irrespective of the integration pattern or a 

combination of multiple patterns that a company uses for B2Bi, the 

final goal is to achieve real-time, secured access to internal corporate 

and external (suppliers, partners and customers) data, which allows 

dynamic collaboration. The integration strategy should be in line with a 

company's business and technology environments and short-term and 

long-term business goals. 

In this chapter, you will learn about the different patterns of B2B 

integration: data oriented integration, portal oriented integration, 

application oriented integration and business process oriented integration. 

We will also discuss how a company can choose its integration strategy 

based on the type of agreement with the trading partners, existing 

infrastructure and level of synchronization desired. 

47


3.1. Types of Integration 

We discussed various benefits, challenges and components of B2Bi in 

the last chapter. But how does the actual integration occur? What are 

the different integration patterns and methodologies used by companies 

in the real world? What are the pros and cons of each pattern? 

These are just a few questions that we will try to find answers for in 

this chapter on the different types of B2Bi. 

There are four fundamental types of B2Bi methodologies or patterns 

(see Figure 3.1) 

1. Data Oriented Integration — This pattern integrates cross-organization 

data through batch processes, replication, data warehouses, data marts 

and data federations. 

2. Portal Oriented Integration — This pattern presents a consistent Web 

interface or presentation layer for all the major applications and 

business processes to the user in a personalized, secured way. 

.J w 

Portal Oriented Integration 

^4_ 

/ 

• s * 

Application Oriented Integration 

M 

I ""I 

Data Oriented Integration 

dpi 

Business Process Oriented Integration 

Figure 3.1. — B2B integration patterns

Integration Patterns 49 

3. Application Oriented Integration — This pattern integrates distributed 

applications by invoking each other's exposed interfaces via standard 

mechanisms, such as Application Programming Interfaces (APIs) and 

Remote Procedure Calls (RPCs). 

4. Business Process Oriented Integration or Event-driven Integration — 

This pattern integrates business processes spread across multiple 

organizations. 

Let us probe deeper into each of these integration patterns. 

3.2. Data Oriented B2B Integration 

Enterprise data and information are typically distributed among multiple 

database management systems and legacy systems. The corporate data 

can reside in databases (relational or object oriented), data warehouses, 

data marts and legacy flat files, e-mails, spreadsheets and other sources. 

A Fortune 500 company frequently has more than 50 different sources 

of data and, usually deploys between 5-7 different database technologies. 

The semantics of all these data sources is heterogeneous, i.e., their data 

modeling and schemas are different. The data sources exist independently 

and their data schema can change at any time. They run on different 

platforms and provide proprietary application programming interfaces 

(APIs) and SQL dialect to interface with them. Applications access data 

from this wide variety of data sources by using non-standard interfaces. 

Data oriented integration attempts to eliminate the use of these 

proprietary interfaces to access data. It gives the power to access data 

from disparate internal data sources over the Intranet and external data 

sources belonging to suppliers and business partners over the Internet, 

using a single standard interface. 

Data oriented integration is the real-time integration (zero latency) 

of diverse internal data from legacy systems, ERP system, CRM system, 

SCM system and other applications with the external data from vendors, 

suppliers and partners. With data oriented integration, the companies 

can easily publish and share their corporate data on the Internet with 

trading partners, regardless of their database system, operating system, 

or networking platform. Such integration supports unified views of


information to all the trading partners and updates synchronously or 

asynchronously across systems. 

Enterprises can achieve data oriented integration through: 

• Data replication solution; 

• Extract, transform and load (ETL) solution using a transformation 

server; and 

• Multi-database server. 

3.2.1. Data replication 

Data replication is defined as the process of copying and maintaining 

database objects, such as tables, in multiple data sources that together 

constitute a distributed database system. Replication means maintaining 

multiple copies of the same data in different physical data sources and 

synchronizing these copies on a schedule-driven or an event-driven 

model. Replication is ideally suited to synchronizing data between 

systems in different locations so that the data source at each location 

has a consistent view of the data without the necessity of accessing 

it remotely. 

Replication is essentially based on distributed database system 

technology to share data among multiple sites. However, there is a 

conspicuous difference between the two: in a distributed system, the 

physical existence of any table is only at the data source, whereas in a 

replicated database the same table exists physically in all multiple data 

sources. Thus, in a replicated database solution, applications can access 

all the data locally, which is not the case in a standard distributed 

database system. 

Replication solution uses a replication server (see Figure 3.2) which 

should be able to handle both bulk and real-time data transfer for 

symmetric and asymmetric database schemas involving multiple data 

sources running on different platforms. It should have a robust fault 

tolerant architecture such as store and forward. In store and forward 

architecture, like the one used by the Sybase replication server, if a data 

movement request fails, data is queued at a source or intermediate 

location and is delivered later when the system is restored. The result is

Propagate 

Change Propagate and 

-•-—— -*J*? 3 Data i^n Route 

Application A '"^^^^j, flM|» Cha "9 e ^ ^ Message 

-^n HBVHKK ». U^H 1 Network 

Application B 


Replication Replication 

Server A Seiver B 

Figure 3.2. — Example of data replication 

Deliver Data 1 1 Deliver Data 

Change! I Change 

Database B Database C 

that users can be guaranteed that the data in their data source is 

consistent and accurate. 

All the leading database vendors such as IBM, Oracle, Sybase, 

Microsoft, Informix, Unisys and Ardent software provide replication 

servers. 

Architectures of data replication solution 

The core architectures of data replication solution include: 

• Primary site data replication; 

• Bi-directional data replication; and 

• Multi-site data replication. 

Primary site data replication 

In this architecture, there is a single, primary data source, known as the 

primary or master site, which maintains the master data. The data is 

replicated from this source to the other data sources (see Figure 3.3). 

All the data replicas only provide read-only access to the data. All the


Large 

Company 

fef 

§£ jfc: 

S"~w g^ -c 

,l *r ^H> «ii- 

Company A Company B Company C 

Figure 3.3. — Primary site data replication 

applications in the system have to access data from the master site in 

order to do any update operations. Replication captures and stores 

changes made to the data at the primary site before forwarding and 

applying them to each data source. 

Bi-directional data replication 

In bi-directional data replication architecture, data replication processes 

run on two or more data sources with each replicating data to one 

another (see Figure 3.4). One of these data sources may even be a 

primary site. In this model, the data that is being replicated from one 

site to another can be the same (all sites maintain master copy of the 

same data) or different (all sites maintain master copy of different data 

segments). Sites that contain a subset of the data are also known as 

snapshot sites.

Master Site 

St 

/ Company A\ 

Snapshot Site Snapshot Site 


Subset 81 * ' Subset 

of Data Sal of Data 

Company B Company C 

Multi-site data replication 

Figure 3.4. — Bi-directional data replication 

Multi-site data replication architecture involves two or more data sources, 

with each data source replicating the exact same data to one another 

(see Figure 3.5). This is a special type of bi-directional data replication, 

which involves dealing with the same data. This architecture takes the 

maximum resources and involves the highest risk of data corruption 

among all the data replication architectures. 

Benefits of data replication 

Replication allows for maintaining the same copy of data in multiple 

physical servers, thereby providing multiple data access points. Thus, if 

the local server is unavailable, users can always point to the remote 

server and continue with their work. 

Furthermore, replication is very useful in the B2B scenario, as 

applications of each company can point to their own internal database, 

rather than connecting to remote databases and accessing the data over 

the Internet. This will make the applications fast and minimize the 

network traffic. However, the timeliness of the data is an issue, as the


Master Sits 

Company B Company C 

Figure 3.5. — Multi-site data replication 

replication for B2B data sources is usually done on a schedule basis 

and not on an event basis. 

3.2.2. Extract, Transform and Load (ETL) solution 

An ETL data integration solution performs the task of extracting, 

transforming, cleaning, routing and loading the data from different 

types of data sources, such as applications, enterprise wide databases, 

data warehouses and data marts, into the target data source (see 

Figure 3.6). It is a single solution of data movement and translation that 

encompasses all the individual solutions implemented in a company in 

the form of data warehouses, data federations and other data integration 

applications. Whether the data resides in DB2, Oracle, Sybase, MS- 

SQL Server, IMS, VSAM, Informix or any other relational or nonrelational 

data source, the solution integrates it seamlessly, thereby 

enabling companies to achieve B2Bi. An ETL-based solution allows 

organizations to filter and publish corporate data securely over intranets, 

extranets or the Internet so that authorized business partners with Web

I Packaged 

implications 

1 (CRM ERR 

| SCM) — j 

Systems '•"••i Extract m+ Transform »•* Cleanse •"•i Load 

Other 

Internal 

Applications 

(C++, Java,. 

Transient Data 

Source 


Figure 3.6. — ETL-based data oriented integration solution 

Data W a reho use 

access can subscribe to the data. Put simply, this solution is a whole 

new class of data access middleware. 

A number of vendors provide ETL solutions, including Data Mirror 

(iDeliver), Acta's ActaWorks, Ascential's DataStage and Informatica's 

PowerCenter. 

Components of ETL solution 

An ETL data integration solution is built on open database architecture 

for easy connectivity to all corporate internal and external data. It is 

usually composed of several tools, including a transformation or ETL 

engine, a scheduler, a designer tool AND a repository that together 

provide end-to-end data integration. 

An ETL solution may be used in conjunction with data replication 

servers to provide a full-fledged data oriented solution within a company. 

ETL engine 

The ETL engine is used for extracting, converting and transforming 

data from a data source and loading it into the target source. It has the 

ability to handle data feeds concurrently from multiple points. The 

engine uses data cleansing tools to identify and correct inconsistent,


redundant and poor data. It uses a staging system or a transient data hub 

to extract, transform, cleanse and integrate data. 

The amount of data to be integrated internally and externally in B2B 

applications can be huge. Thus, the ETL engine should be capable of 

providing high scalability and high data throughput for the movement 

of data from the origin to the destination by supporting functionalities 

such as in-memory data transformations, in-memory caching, query 

optimization and multithreading. 

The ETL engine can function in the following ways: 

• If the data sources to be integrated are completely heterogeneous, 

making local transformation impossible, the ETL engine extracts data 

from the origin data source, transforms and routes and loads data to 

the target data source (see Figure 3.7). In this environment, 

sophisticated ETL functionalities of pulling data from multiple 

operating environments, applying transformation rules and then loading 

data into target applications are required. 

• The load on the engine and the unnecessary use of network bandwidth 

would be a lot less if aggregations, consolidations and other 

transformations of data occur right at the data source level. In this 

approach, the data is partially transformed right at the data source, 

extracted and further transformed by the engine before routing it to 

the target data source where further transformation may take place 

(see Figure 3.8). 

• In this approach, the complete transformation occurs at the source 

and/or target data source (see Figure 3.9). There is no extraction and 

Extract Load 

Data Transform Data 

Data 

Source Target 

Database Database 

ETL 

Engine 

Figure 3.7. — Data transformation performed by the ETL engine

Transform 

lata 

Source 

Database 

Figure 3.8. 

sources 

Extract 

Data Transform 

Data 

ETL 

Engine 


Transform 

Load ! Data 

Data 

Target 

Database 

Data transformation performed by the ETL engine and data 

Transform 

Data 

ETL 

Engine 

Tan storm 

Data 

T£- am Source 

aill 

Cbmm 

Database 

lands^^^ Datz 

"^ Extract 

Load 

Tiansform 

Data 

Target 

Database 

Figure 3.9. — Data transformation performed by data sources


transition of data through the engine, making this process the fastest 

of all the three approaches. Here, the ETL engine simply brokers the 

Structured Query Language (SQL) instructions between the source 

and the target. 

Designer tool 

The designer tool provides a graphical user interface to specify data 

mappings, transformations, process rules and flow movement processes. 

The data is transformed, based on the transformation rules defined by 

the user. The process rules define the dependencies to control the flow 

of data. For instance, if the values in one of the target tables (let's say 

A) is dependent on the values of the other target table (let's say B), A 

cannot be loaded until B has finished loading. The transfer of the data 

can be in real-time or batch mode, as defined by users. 

Metadata repository 

Metadata is information about data such as length, description and the 

data source it belongs to. For instance, metadata for a data element 

"customer_id" will be its length (8 characters), location (CRM database) 

and its description (id for each customer in the CRM database). 

A metadata repository stores and manages metadata about data along 

with the transformation rules. 

Scheduler 

The scheduler is used in an ETL solution for programming, deploying 

and controlling processes that can be scheduled to execute on an event 

or calendar basis. 

Benefits of ETL solution 

ETL solution is best suited for creation and maintenance of data 

warehouses and data marts. ETL data integration software works in 

conjunction with products from enterprise application integration vendors 

and process integrators, not in lieu of them. For instance, a data


warehouse built using an ETL solution can work with a message broker 

to provide integration with multiple applications. 

3.2.3. Data warehouses and data marts 

Data warehouse 

A data warehouse is defined as a data source that consolidates operational 

data from multiple sources and uses consistent physical attributes, 

naming conventions and semantics. The data is extracted from multiple 

data sources, including legacy systems in different formats, transformed, 

cleansed and then finally loaded into data warehouse, using an ETLbased 

solution. Thus, a data warehouse presents a single, consolidated 

view of cleansed data. Since it actually holds the data physically, unlike 

a virtual data warehouse, the performance and speed of database 

operations are much faster. The applications only require information 

about a single SQL dialect or database API with which they can 

interface with the data warehouse. 

Data warehouses should be application neutral, i.e., they should not 

be based on application or process oriented modeling methods. They 

should have the breadth to include all the data elements in internal and 

external data sources, which makes them more flexible and usable by 

multiple applications. 

In the majority of cases, data provided by data warehouses to 

applications is not real-time and is only refreshed and synchronized on 

a monthly, weekly, daily, hourly or even on a minute-to-minute basis, 

depending on the operational requirements. 

Data warehouses pose implementation challenges if the data in them 

is updateable, with the requirement that the changes have to be 

propagated back to the effected data sources. In such scenarios, a 

combination of data warehouses and integration brokers (message 

brokers) may work very well (see Figure 3.10). 

Data marts 

A data mart is defined as a data source, which contains only a subset of 

the contents of a data warehouse. It contains summary or detail level


SCM System 

CRM System 

Legacy 

System 

I 

Enterprise Data 

Warehouse 

ERP System 

Internal 

Applications 

Figure 3.10. — Data oriented integration and message broker 

data that is focused on a specific business unit or a line of business. 

Since data marts contain limited but focused data, they offer much 

faster query processing as compared to data warehouses. 

A data mart can be populated directly from operational data sources 

using an ETL-based data integration solution as used for data warehouses, 

or it can get its data from a data warehouse. Figures 3.11, 3.12 and 3.13 

show the different topologies of data marts and data warehouses. 

Coexistence of data warehouses and data marts 

Several companies implement a combination of data marts and data 

warehouses to solve their integration needs (see Figure 3.14). It is not a 

bad solution to take the load of warehouses by using data marts as 

repositories of specialized data, but a company should not build excess 

data marts, as it would require maintaining and building additional data 

sources leading to higher costs. Thus, the direct usage of data marts 

should be limited and the users should access data directly from 

warehouses whenever possible. 

3.2.4. Multi-database server 

A multi-database server, also known as universal data access server, 

provides an abstraction layer to access multiple databases and legacy

Operational Data Source* 

. J 

Users 


Legacy 

System 

Figure 3.11. — Data marts get data from operational data sources and users 

retrieve data from data marts 

Data Mart 

Data 

Warehouse 

Data Mart 

Figure 3.12. — Data marts get data from data warehouse and users retrieve 

data from data marts and data warehouse


Users 

Data Mart Data Mart 

Data Mart 

Data Mart 

Users 

Figure 3.13. — Data marts get data from data warehouse and users retrieve 

data from data marts 

Operational Transient Data Data 

Data Sources Data Hub Warehouse Marts 

Legacy System 

Operational 

Database 

Operational 

Database 

-I 

Users 

Purchasing , 'Data Mining 

Sales 

Data 

Reporting 

Data Analysis 

Figure 3.14. — Coexistence of data warehouses and data marts


systems — all of which may run on different platforms and hardware, be 

supplied from different vendors, have different data schemas and support 

their own dialect of structured query language (SQL). Multi-database 

servers provide a single, consolidated view of the data from multiple 

sources without physically moving the data from one source to another, 

thereby eliminating the need to construct a separate database of redundant 

data. An application which interfaces with a multi-database server does 

not have to know anything about the underlying data sources, as the 

multi-database server provides mapping, type conversion and multi-data 

source joins and unions. The server provides full transaction integrity 

by using two-phase commit protocol for write operations which spread 

across multiple data sources. The server also acts as a storehouse of 

views for read-only operations, which may also span across multiple 

data sources. 

Multi-database servers are one of the emerging solutions for data 

oriented integration. Apart from integrating internal data sources, they 

can transparently access data from business partners' data sources over 

a network, if they are connected to Web gateways, all through the use 

of only a single interface and a single SQL dialect. These servers can 

work together with replication tools, or may even support replication 

functionality implicitly. 

For instance, there can be any number of applications connected to 

the multi-database server using either ODBC or JDBC APIs. The 

individual applications do not have to know about native API or SQL 

dialect of each data source. The server interfaces with all the data 

sources and invokes operations on them based on the requests received 

from the applications. 

Several companies, such as Oracle (Transparent Gateway), Sybase 

(OmniConnect), DB2 (DataJoiner), Attunity (Connect), provide such a 

solution. The support for various data sources differs from product to 

product. 

Oracle's Transparent Gateway (see Figure 3.15) provides the flexibility 

to access transparently more than 40 non-Oracle systems, including 

Microsoft SQL Server, IBM DB2 and Sybase. 

IBM's product DB2 DataJoiner (see Figure 3.16) supports various 

data sources, including all members of the IBM DB2 family, Microsoft 

SQL Server, Oracle, Oracle RDB, Sybase, Sybase Anywhere, Informix


ODBC 

Application 

Windows 

IMS 

\JSAM 

via Classic 

Connect 

Other 

Java 

Application 

C++ 

Application 

Oracle Database Server 

Heterogeneous Sere ices 

I 

Oracle Transparent Gateway 

1 

N on- Oracle 

system 

Figure 3.15. — Oracle transparent gateway 

AroZnfo, 

AroView, etc 

Gateway 

VB 

Application 

OS/2 MX Othres Macintosh j Solaris HP-LXX 

I 

DB2 i>aiaJoin«r 

DB2 Universal Database 

Enterprise & 

Ents ip lise-Exten d ed 

Erfittmsfor AK 

DB2 Edition 1^3 

Grade 

Oracle Rdb 

Informix 

DB2 Universal Databases for A3X 

DB2 Universal Databases for HfHJX 

DB2 Universal Databasesfot Solans 

DB2forATX 

DB2forW>-UX 

M»- DB2for Solaris 

DB2forSinx 

DB2 Universal Databases Enterpiise & 

Enterprise-Extended Editions for Windows NT 

DB2Universal Database for Windows NT 

DB2 Universal Database for 06/2 

DB2for Windows NT 

DB2 for AS/400 

DB2fot OS/2 

DB2forSCO 

Merosoft SQL Seivei 

Sybase SQJ-Anywheie 

Sybase 

DB2 foi 

YSE&VM 

Figure 3.16. — IBM DB2 DataJoiner 

DB2 Universal Database 

for OS/90 

DB2 for MVS


Online and several others (including non-relational DBMSs). Further, 

since DB2 DataJoiner is an extension of the DB2 base product, it is 

capable of storing and managing its own local data objects, such as 

tables, views and indexes. The optimizer provided with DataJoiner 

considers the disparate and physically distributed nature of its 

environment, so that an efficient data access strategy can be selected for 

each query. 

DB2 DataJoiner V2.1.1 provides transparent Data Definition Language 

(DDL) support, which gives greater flexibility in managing a 

heterogeneous environment. 

The real fact 

We have to know the real fact, as bitter as it may be. Though the multidatabase 

server concept looks good on paper, it is still not popular for 

B2Bi because it lacks performance and integrity. It is based on the 

concept of distributed database operations (such as select, update, insert) 

and run-time conversion of SQL to native database calls, which is 

potentially slow and completely dependent on the availability of the 

network that connects the server to every single data source. Furthermore, 

it does not take away the complexity involved in identification and 

transformation of the source data and data mapping from one source to 

another, as required by an actual physical data warehouse. 

Since this solution neither captures the data nor stores it physically, 

it requires extraction and transformation from multiple data sources for 

every query that it runs. This is both slow and expensive as it uses a lot 

of network bandwidth. 

In its current state, this architecture is only good for small integration 

projects which involve the integration of simple data sources containing 

high quality data. According to the Gartner Group, by 2005 multidatabase 

architecture will remain an opportunistic approach for integrating 

only two to three relational data sources to meet simple business 

intelligence requirements. 

3.2.5. XML and databases 

Extensible markup language (XML) can be of tremendous use in data 

oriented integration. The capabilities and functionalities of databases


and XML compliment each other. Databases offer a very efficient 

means of storing data, while XML offers very efficient means for 

exchanging data to enable interoperability among heterogeneous 

applications and data sources. 

If all the companies participating in B2Bi can share common XML 

schemas, the data sources within each company can expose and exchange 

data in XML format. The data flow in this scenario would involve the 

movement of data from the origin to the destination in the form of 

XML messages. 

XML documents can be stored and retrieved from databases as 

images, XML native data type or regular data types after parsing the 

document using regular SQL commands such as SELECT, INSERT, 

UPDATE. A parsed XML document can be stored in a relational 

database management system as multiple tables and rows as relations. 

Databases also provide a repository for storing XML document type 

definitions (DTDs). 

Several leading relational databases such as Sybase, DB2, Oracle, 

MS-SQL Server already provide direct support for data transfer in 

XML format, i.e., there is no need of intermediary application to pull 

the data from the data source and then format it in XML. 

For instance, IBM's DB2 XML Extender provides an end-to-end 

solution for storing and retrieving XML documents. Similarly, Sybase's 

Adaptive Enterprise Server (Version 12.5) fully supports XML and 

provides a built-in search engine for XML documents. 

XML layer over data oriented integration 

Even if the existing data sources in a company do not support direct 

storage and retrieval of XML documents, it can still leverage the 

benefits of using XML for integrating cross-organization applications 

by using an XML layer on top of data oriented integration. With data 

oriented integration, a company can build data warehouses and data 

marts for internal data sources. With an XML layer that includes an 

XML repository for storing XML schemas, data can be transformed and 

then exchanged with all other trading partners, providing seamless B2Bi 

(see Figure 3.17).

WebSite 

(Intra netj ^ 

XML 

Schema Database 

ETL 

Transformation 

Process 

Operational Systems 

•Jl 

XML 

~* Transformation 

Process 

Data 

Warehouse 

-I 

Data 

Ma it 


Figure 3.17. — XML transformation over data oriented integration 

3.2.6. Data oriented integration and B2Bi 

Data oriented integration can either be real-time (such as synchronous 

replication, stored procedures, virtual data warehouses) or non-real-time 

(such as asynchronous replication, batch transfer, scheduled extraction 

and transformation). The level of integration, transformation and 

timeliness of data are decided by the data oriented integration solution 

implemented by a company with its partners. A Fortune 500 company, 

typically, uses a combination of all the above solutions to achieve its 

integration goals. 

One of the most challenging tasks of data oriented integration is 

synchronizing the semantic discrepancies that exist in different data 

sources. Each data source may be supporting one or more business unit 

of the company. The data elements in these data sources may have the 

same names and formats, but have different meaning and association, 

based on the business unit they support.


In order to have long-term benefits of data oriented integration, a 

company needs to set a single standard for defining data elements 

across all data sources. 

3.3. Portal Oriented Integration 

Portals provide a Web front-end or presentation layer for supporting key 

business functions involving online transactions such as sales, marketing, 

customer service and enterprise-wide communication and sharing 

information with the customers, trading partners and internal employees 

of a company. According to the definition provided by IBM, portals 

provide a secure, single point of interaction with diverse information, 

business processes and people, personalized to a user's needs and 

responsibilities. Portal users have a Web browser to access and interact 

with Web applications hosted by the company. Accessed content and 

data in the portal may reside virtually anywhere: on the intranet, the 

Web, relational databases and data warehouses, file systems, enterprise 

resource planning systems (e.g., MySAP) or other enterprise applications. 

A typical example of use of Web portals in a B2B scenario is a 

buyer logging on to their account maintained on a supplier's portal and 

checking on product availability, pricing and placing an order. After 

placing an order, the buyer can check on the status of order fulfillment 

and shipment through the portal. If the buyer uses the supplier's portal 

often, the portal will recognize the buyer and offer personalized services 

based on the buying pattern and preferences of the buyer. 

Today, Web portals are an important component of any company's 

B2Bi strategy. They provide a very quick and efficient way to establish 

and maintain a business relationship and to add value to all interactions 

conducted through it by providing personalized services. Portals enable 

collaboration among the trading partners by including tools which help 

large, distributed and cross-organization teams to work together and 

communicate across distance, time zones and company borders. Through 

portals, suppliers, buyers, manufacturers and distributors can streamline 

their supply chains and other shared business processes. Furthermore, 

portals provide anytime (24/7/365), anywhere access to information 

over the Web and a scalable infrastructure for handling large volume


interactions and transactions. Finally, they provide very effective search 

and navigation facilities by categorizing repositories of content and 

searching them for relevant information. 

3.3.1. Types of portals 

Portals are grouped into two categories, horizontal and vertical. 

Horizontal portals form the core services layer that offers the 

infrastructure on which all vertical portals are built (see Figure 3.18). 

Vertical portals, which are domain specific, represent only an instance 

of a portal that is built upon the horizontal portal. Vertical portals are 

also known as vortals. 

For instance, in a typical Fortune 500 company there may be several 

vertical portals, such as employee portal, consumer portal, supplier 

portal and sales service portal which are built on top of the horizontal 

portal infrastructure. Once the horizontal portal is built, adding on 

vertical portals is relatively inexpensive. Each vertical portal can be 

aligned with a particular business goal of the company. 

A survey of 550 professionals by Delphi Group, a Boston-based 

consultancy, showed that at the end of 2000, 54% thought that their 

companies would develop multiple vertical portals by the end of 2002. 

B2B vertical portals are also known as B2B exchanges. They 

usually focus on procurement, supply chain management and other 

specialized services, such as legal and financing. A vortal can just be 

information oriented or may offer transaction services. For vortals to be 

successful, the formation of a community that provides the business 

services needed to support B2B transactions is essential. 

Internal 1 p_ , 1 I 

Employee 1 P "porta| T ' e I Customer Portal I Supplier Portal 

Portal 

Horizontal Portal Infrastructure 

Figure 3.18. — Vertical portals are built on horizontal portal infrastructure


Company 

Portals 

Portal 

Server 

E-procurement 


Relationship 

Management 

Business Partner Web Customer 

u 

Presentation Layer 

Employee 

Investor 

Sei vices Lay ei (Personalization, Collaboration, 

Integration* Seaich, Indejdng, Secui ity, Publish/Subset ibe) 

Connection Layer 

\ X 

i i 

Internal and 

External Trading Partner Applications and , ^ , Applioat[an:! and DotaSourca 

external Data Sources ^ 

Resources 

Figure 3.19. — Portal framework 

Note: B2B exchanges are covered in great detail in the chapter on B2B 

e-marketplaces and collaborative networks. 

3.3.2. Components of a portal server platform 

An enterprise portal server framework provides open services and 

interfaces that are used together with a development kit to customize 

the features of the presentation layer, services offered and connections 

to enterprise applications (see Figure 3.19). A portal server should be 

able to fully leverage an enterprise's existing infrastructure such as 

application servers, databases, legacy applications (mainframes) and 

packaged applications (ERP, CRM) through the use of pre-built 

components. 

A portal server consists of some essential components that form the 

presentation layer, services layer and integration layer. Dividing the 

portal server framework into structured layered components for


presentation, content, business logic and integration makes site 

maintenance and updates relatively easy. 

Vertical portals have much in common as far as functionality and 

connectivity issues required to build dynamic user interfaces are 

concerned. The framework should provide all the common features as 

an out-of-the-box solution, leaving the other uncommon features such 

as business logic and visual design — which are unique to each 

company and each vertical portal. It must, however, provide a platform 

to facilitate rapid, value-added development of these features, including 

the presentation layer. Companies can use generic templates of user 

interfaces as the starting point, rather than developing the whole code 

from scratch. 

The data presented by portals comes from several heterogeneous 

sources that include legacy, relational, packaged and partner data sources. 

Thus the portal framework has to provide connectivity or integration 

with enterprise applications. In fact, portals are built on top of EAI 

platforms. 

Presentation layer 

The presentation layer is responsible for providing a user-friendly frontend 

interface to users. Through this layer, users view and interact with 

the data. A very basic example of the presentation layer is an HTMLbased 

front-end of any Website. Java Server Pages (JSPs), Active 

Server Pages (ASPs), VBScript, JavaScript, Java Applets, ActiveX, 

Dynamic HTML, Cascade Style Sheets (CSS), WML and cHTML are 

some of the other presentation technologies. A front-end may be built 

using one or a combination of these technologies. In some cases, the 

interface can even be a custom developed application in Visual Basic 

(VB), Visual C++, or Java that runs on the user machines as a standalone 

application. However, this will not be the case with a true Web 

portal application. 

Services layer 

The services layer provides foundation infrastructure on which portals 

are built. This layer resides between the presentation and the connectivity


layer. Services offered by this layer include session management, logging, 

security, personalization, document management, workflow management, 

subscription and notification and search and indexing. It also provides 

an API through which other enterprise applications, external applications 

and legacy systems could be integrated into the portal environment. 

The services layer components include an application server, an 

SMTP server, a Web server, an LDAP server and an administration 

server. All these components together provide a highly scalable, reliable 

and robust architecture that can handle large enterprise systems and 

heavy traffic on the portal. The services layer offers features such as 

load balancing, distributed transaction control, message translation and 

the ability to handle multiple component types (EJB, COM, COM+, 

CORBA). 

The application server, the heart of a portal framework, should 

ensure maximum portability and flexibility by being built on a standards 

based architecture that includes support for all the leading technologies 

such as CORBA, RMI, EJB, XML, .Net and SOAP. Further, it should 

enable an end-to-end integration from the Internet to the mainframe. 

The Web server is an HTTP-based server for hosting static content 

and dynamic Web applications. It acts as a container and distributor of 

a collection of HTML/XML pages, JSPs, Servlets, Java classes, applets, 

ASPs, images, multimedia files and other file types. It provides high 

performance and availability through page caching, session state 

management and application server integration. 

The SMTP server is responsible for managing the e-mail flows 

through the portals. The e-mail addresses of the portal users are exposed 

to the enterprise e-mail server via the LDAP server. The portal framework 

should implement a WebDAV server, which is an Internet standard for 

accessing documents over the Web protocol HTTP using XML encoding 

of data. 

The administration tool gives a single point of monitoring and 

management of the system. 

The core services offered by the service layer are: 

Personalization — Personalization features most commonly associated 

with portals are the ability to offer views of content based on a user's 

organizational role and for end users to customize their interfaces. The


ability for the end user to explicitly state preferences and create a 

personalized 'My HomePage' is an important element of the portal 

concept. However, an enterprise portal will only be as good as the 

structure and organization of the underlying data. Personalization services 

are made possible by behavior tracking feature of portal software. 

Behavior tracking records page impressions, 'click-throughs,' 'add-tos' 

and removals from shopping carts and purchase and order histories, for 

use in analysis of customer shopping and buying patterns. 

Collaboration — Today, e-mail alerts of new content relevant to the 

end user are common. Many portals integrate with existing collaboration 

environments, allowing e-mail and group calendaring features from 

Lotus Notes or Microsoft Exchange to be accessed via the portal 

interface. Also common is the incorporation of collaborative features, 

such as threaded discussions or chat, into the portal application itself. 

Some portals focus on project management or communications between 

enterprises. In these instances companies should look for portal products 

that provide for group work spaces, white boarding and team document 

sharing. 

Directory — The portal server should provide a cross-platform, scalable 

and robust common directory service such as Lightweight Directory 

Access Protocol (LDAP) to address the proliferation of applicationspecific 

directories. 

Subscription and Notification — The portal server should offer rich 

subscription and notification services. The users of the portal should be 

able to subscribe for events, discussions, documents and chats. 

Notifications are triggered when any underlying data for which the user 

has subscribed changes and can be sent through e-mails, over PDA 

devices or placed in the personal portal of the user. A very simple 

example of subscription is that of an investor subscribing to news and 

quotes for a particular stock on a financial portal. The investor should be 

notified of news and quotes of that stock through the investor's preferred 

mode, such as e-mail or message over a handheld wireless device. 

Search — The portal server should offer a very powerful search facility 

through which users can locate relevant information based on content, 

metadata, author, date or type of information.


Security — The portal server should provide a comprehensive security 

architecture that encompasses access control, cryptography-based privacy, 

digital certificates, secure socket layer (SSL) and user authentication. 

Connection layer 

The portal server has to provide a connection layer through which 

structured and unstructured data can be retrieved from data marts, data 

warehouses, databases, e-mails, internal applications, legacy systems 

and external customer feeds. 

3.3.3. Portal oriented integration and B2Bi 

Portal oriented integration is not as complex and expensive as other 

integration patterns. Several small to medium size companies are using 

this integration pattern for B2Bi to avoid the much sophisticated and 

involved integration of back-end systems. Through portals, a company 

can provide a Web interface to their key business systems such as ERP, 

CRM and other legacy systems. 

Portal oriented integration fails in most cases to achieve true B2B 

integration. Most portals do not have sophisticated business process 

management tools built in which the transfer of data based on business 

events can automate. 

We have covered all the integration challenges and their workarounds 

for vertical portals in the chapter on B2B e-marketplaces and 

collaborative networks. 

3.4. Application Oriented Integration 

Application oriented integration involves the direct application-toapplication 

(A2A) integration of cross-organization and cross-platform 

application over a network. This type of integration is usually 

synchronous in nature. Application oriented integration can range from 

custom code (COBOL, C++, Java) to application programming interfaces 

(APIs) to remote procedure calls (RPCs) to distributed middleware such

y """X, 

./ \ Request 

I Client J^^^^^^T 

\ J ' w ~~ Response 


1 Server 

Figure 3.20. — Synchronous communication (Request/Response) 

as TP monitors, distributed objects and message oriented middleware 

(MOM). 

A2A integration requires integration of new technology with the old, 

realizing a common architecture where all business-enabling applications 

are able to communicate with each other. It enables companies to 

connect and coordinate data and events among multiple, crossorganization 

applications. 

Application oriented integration is primarily synchronous in nature, 

i.e., it is based on request/reply interactions between the client (requesting 

program) and the server (responding program) (see Figure 3.20). Thus, 

the middleware supporting this integration pattern has to provide adapters 

and an adapter toolkit, to develop custom adapters that support 

synchronous program invocation. 

In this section, we will discuss APIs and RPCs. The discussion on 

different technologies such as CORBA, RMI and TP monitors is provided 

in the chapter on middleware technologies. 

3.4.1. Application Programming Interfaces (APIs) 

An application programming interface is a group of functions or methods 

defined by programs, which external programs can invoke to interact 

(select information, update information, control the state or notify the 

events) with the underlying applications. Just as a keyboard is the 

interface for a computer, an API is the software interface for applications, 

programs and operating systems. An invocation of each method of an 

API is supposed to generate a desired outcome. APIs encapsulate the


Application A Application B 

API Calls I I API Calls 

Data Access Layer 

Data Source Data Source 

Figure 3.21. — A typical API call 

underlying business logic and data access, providing a higher degree of 

security and data integrity. 

APIs provide a high-level programming paradigm, where an 

application or a program does not execute its own methods or functions 

itself but makes some other applications or programs to do it. This way 

the actual implementation of the method or function is always delegated 

to the program publishing the API and not the calling programs (see 

Figure 3.21). If there is any change in the business logic, which requires 

changing the implementation of the method, the developers have to 

change the code at only one place, i.e., in the program providing the 

implementation of the method — as long as the incoming parameters 

and output do not change. 

For instance, applications and programs developed on any operating 

system use APIs provided by the underlying operating system. This way 

they are able to delegate all the dirty work of disk Input/Output (I/O), 

memory allocation, painting graphics on the monitor, etc., to the operating


system programs. Therefore, if a program has to read some data from a 

file or write some data to a file, all it does is invoke a method on the 1/ 

O API provided by the operating system and let the operating system 

perform the task of seeking, reading and writing from the hard disk bit 

by bit. 

Most of the packaged applications such as ERP, CRM and SCM 

provide APIs to interact with the underlying application and business 

objects. These APIs are independent of the platform and programming 

language. This feature gives companies flexibility in terms of integrating 

their already developed internal applications, irrespective of their 

language and platform, with the packaged software. 

Usually all the APIs are synchronous in nature, i.e., the function call 

does not return until the specified action is complete. However, if the 

application invoking a function call through an API does not want the 

client process to wait indefinitely, it can spawn a new thread process to 

handle other tasks. 

Components of APIs 

There are several components of an application programming interface, 

as follows: 

Interfaces — Interfaces contain the signatures or definitions of the API 

functions. They are distributed and used by all the client programs to 

invoke API functions. A typical function signature contained in an API 

will have the following information: 

• Name of the function or method; 

• Input parameters; 

• Return type (output); and 

• Any exceptions thrown by the function. 

Methods or Functions — The methods or functions contain the actual 

code that performs the tasks defined by the API and are defined and 

contained in the underlying programs. If there is any change in the 

implementation of a function, its function code has to change. 

Input and Output Parameters — Each API function can take multiple 

input parameters and may return an output. The input parameters and


the output may be a user-defined type or a system-defined type. Userdefined 

types are used for storing groups of related information by 

containing combinations of multiple individual data members. This 

grouping and encapsulation of data helps in passing a single input 

parameter instead of a large number of parameters and/or returning a 

logical object that contains all the data as desired from the output of a 

method call. 

Named Constants — In several cases, APIs use fixed numeric or string 

codes, also known as constants, to represent some kind of constant 

information or value. Naming these constants provides a more convenient 

way to refer to their values in code. 

Callback Functions — Callback functions are an optional feature of an 

API. Callback functions are regular functions defined in the programs 

implementing APIs with the exception that they are never made available 

through an interface. They are used internally by one or more of the 

API functions to perform the task. 

Classes of APIs 

Based on their functionality and uses, APIs can be classified into five 

different classes. Although there is considerable similarity in these 

classes, they broadly cover all the different approaches in which packaged 

applications (i.e., ERP, CRM, SCM), databases, legacy systems or 

custom developed applications can expose their methods in the form of 

interfaces. 

Method APIs — Method APIs provide an interface for a series of 

methods or functions exposed by an application, which the external 

applications can invoke. Each method is defined by a name, a set of 

input parameters (which must be provided by the calling application in 

order to use the method), output type and exceptions. 

Several leading packaged software vendors provide linkable libraries. 

For instance, external applications can access SAP Business Objects 

through standardized, platform-independent interfaces — Business 

Application Programming Interfaces (BAPIs).


Messaging APIs — Messaging APIs provide a flexible message oriented 

interface that enables communication between message-based applications. 

The API makes it easy for enterprises to write business applications 

that asynchronously send and receive critical business data and events. 

For instance, the Java API for XML Messaging (JAXM) enables 

applications to send and receive document oriented XML messages 

using a pure Java API. With the use of JAXM, application developers can 

focus on building, sending, receiving and decomposing messages for their 

applications instead of programming low level XML communications 

routines. 

Component/Object APIs — Object APIs provide interfaces that can be 

used by applications to access different objects, which encapsulate the 

data and business processes. 

Several vendors of distributed component solutions such as DCOM, 

CORBA and EJB provide APIs to access remote objects. 

Data Management APIs — Data management APIs provide interfaces 

containing methods for directly accessing and manipulating an 

application's database or any other data source, internal or external to 

the company. This API should not only allow the retrieval of downloaded 

data or data in databases, it should also support data management 

activities common to most applications. This API enables data 

management applications to be integrated much like ordinary software 

applications, as it provides a consistent, platform-independent interface 

for integration. 

A typical example of data management API is structured query 

language (SQL). Each database vendor implements and supports its 

own flavor of SQL. For example, Oracle provides PL/SQL, Sybase 

provides transact SQL. 

Sun's JDBC API is a Java API for accessing tabular data which 

makes it easy to send SQL statements to relational database systems 

and supports all dialects of SQL (see Figure 3.22). The JDBC API 

consists of a set of classes and interfaces written in the Java programming 

language that provides a standard API for tool/database developers and 

makes it possible to write database applications using an all-Java API. 

The JDBC API contains two major sets of interfaces: the first is the


r JDBC 

JDBC-ODBC 

Bridge Driver 

Database 

Client Library 

t 

Database 

Server 

Java 

Application 

"W" 

JDBC API 

Driver 

Manager or 

DataSource Object 

1 Partial Java 

JDBC Driver 

Database 

Client Library 

Database 

Server 

Figure 3.22. — JDBC API — An example of data management API 

JDBC API for application writers and the second is the lower-level 

JDBC driver API for driver writers. 

File APIs — File APIs provide interfaces containing methods to manage 

file information, access data and catch events from legacy applications, 

which usually contain data in flat files. The interface encapsulates many 

of the advanced file and shell related functions. 

Applications can use file APIs to extract particular data elements 

from the legacy system. The API will take care of any logic or 

arithmetic needed to produce the desired data. Without this API, 

integration of legacy systems would be a nightmare, as they do not


publish interfaces (i.e., they do not support program-level access to 

internal business objects). 

Key requirements of an API 

There are several essential requirements of an API, which makes it 

usable for B2Bi applications. Some of them are: 

Easy to Use — An API having even the most advanced functions will 

not be accepted well by the users, if its interface is not easy to use. The 

thumb rule in writing any API should be to make it as easy as possible 

for the users to use it. An API should be well supported through proper 

documentation and examples. 

Language and Platform Independent — The use of APIs in B2Bi 

applications will be very limited if their use is bound to a specific 

programming language and platform. Two companies trying to integrate 

their internal applications using APIs may have the underlying 

applications running on different platforms and developed in different 

applications. Thus, APIs should be language and platform neutral. 

Protect the Underlying Data Sources — The API functions should be 

written in such a way so as to allow completely direct access to any 

underlying data sources. This requirement is especially important for 

B2B applications in which users of one company use APIs to access 

data from another company. If the APIs mistakenly provide access to 

the data source, the users can maliciously change the data. 

Controlled Access — The APIs should provide controlled access to 

each user set. Based on the entitlements of the users, the APIs should 

provide restricted functionality in terms of invoking functions. 

Support for Multiple Data Sources — APIs should provide support for 

different types of databases. The APIs should hide the details of each 

database format from the calling program. 

Limitations of APIs 

There are no industry standards for creating an API. Consequently, 

the structure and implementation of APIs can differ significantly


from application-to-application. With most middleware, 'wrappers' are 

developed (distributed objects) or messages queues employed (MOM) 

to provide a uniform communication standard between APIs. 

Invoking API functions from applications developed in different 

programming languages requires an application broker in between to do 

the data type conversion. This makes the calling application errorprone, 

which now has to deal with all kinds of interoperability issues, 

including hard-to-find problems such as pointers and terminating nulls. 

Most of the APIs do not allow for customization of the application 

interface to better suit the needs of the user. Furthermore, API level 

integration makes the application tightly coupled, which has some 

serious drawbacks. These drawbacks are discussed later in the chapter 

under the heading Application Oriented Integration and B2BL 

3.4.2. Remote Procedure Calls (RPCs) 

RPCs provide a high-level communications paradigm for network 

applications using which the applications can invoke procedure 

calls across a network, irrespective of the underlying network. RPCs 

enable communication and integration of local and remote applications 

on a procedure or method level. They allow local applications to draw 

on the resources of remote systems and can set up cause-and-effect 

events. 

The independence from the transportation layer feature of RPC 

makes it very useful in B2Bi as it can integrate cross-organization 

applications irrespective of the underlying networking mechanisms. 

Further, RPCs also hide other technical details of making a remote call 

such as parameter marshaling and context management. 

The current implementations of RPC include: Common Object 

Request Broker Architecture (CORBA), Java's Remote Method 

Invocation (RMI) and Microsoft's Distributed Component Object Model 

(DCOM). 

How to make a remote procedure call? 

RPCs enable programs to call or execute predefined functions in the 

same system or a remote system. Before we discuss how to make a


remote procedure call, let's review some of the key terms of RPC 

protocol. 

Client — A client is an application or program that makes remote 

procedure calls to remote servers. Irrespective of the language in which 

the client is developed, it needs to know the following in order to make 

a remote call: 

• The uniform resource locator (URL) and transmission control protocol 

(TCP) port of the server; 

• The name of the remote procedure; 

• The kind and number of arguments that procedure expects; and 

• The kind and number of return values. 

Server — A server is a process that provides remote services to clients. 

Remote Service — A remote service is a collection of one or more 

remote programs available over the network. 

Remote Program — A remote program implements one or more remote 

procedures. 

A remote procedure call involves a single thread that controls 

two processes. One of the processes is that of the calling program 

(caller's process) or application and the other one is that of the server 

on which the call is being made (server's process). The caller process 

initiates the communication by sending a message with the remote 

procedure's parameters to the server process (see Figure 3.23). After 

sending the message, the caller process can wait for the server process 

to respond back with the results of the remote procedure (synchronous 

communication) or continue on (asynchronous communication). The server 

process, on the other hand, is dormant waiting for the client requests 

and servicing them as the RPCs are invoked. Once it receives a message 

from the client program, it executes the remote procedure and sends the 

calling process the results in the form of messages. 

In the above implementation example, there is only one process that 

is active at any moment in time. RPC protocol supports simultaneous 

execution of more than one process. For instance, in an asynchronous 

RPC call, the client process can continue without waiting for the results 

from the server process.


RPC Client 

Calling 

Code 

RPC 

Interface 

Client 

Stub 

RPC 

Runtime 

jk %. 

Apparent Path of 

Procedure Call 

• 

Apparent Path 

of Data 

Return Data 

Input Arguments 

RPC Server 

Remote 

Procedure 

RPC 

Interface 

Server 

Runtime 

RPC Runtime 

Figure 3.23. — Real and apparent paths of RPC call and data flow 

RPC-based integration can either be synchronous or asynchronous in 

nature. A synchronous function or method call will hold up the execution 

of an application while it awaits a response from the remote method. 

As an example, assume that there is a remote procedure for retrieving 

customer information. The details of the RPC are given in Table 3.1. 

XML-based RPCs 

B2B applications that communicate using RPC can fully leverage XMLbased 

technology to communicate in a standard way over the Internet 

using HTTP. RPCs, based on XML, work by encoding the RPC request 

from the client to the remote server in an XML message (see Figure 3.24). 

The message is then sent over the Internet to the server. On receiving 

the message, the server decodes it, executes the remote procedure and 

A 

A 

A 

A

Procedure 

Name 


Table 3.1. An example for RPC to retrieve customer information 

Host: http://165.107.65.25/rpc Port: 8080 

get_customer_info 

I XML-RPC 

 

Procedure Definition 

Input 

Request 

Output 

 

XML-RPC Response 

Client Server 

Figure 3.24. — RPC based on XML messages 

Description 

For a valid 

customer_id, the 

remote procedure 

will return the 

details of the 

customer as a 

struct type. The 

structure will have 

the following 

fields: 

firstname 

lastname 

phonenumber 

faxnumber 

e-mail 

sends the results back to the client after encoding them as XML 

messages. The client then decodes the XML message into standard 

language data types and continues on. 

As an example, let's consider the same example of a remote call for 

retrieving customer information with XML-based communication. 

•


XML request message sent from the client to the server: 

 

 

get_ _customer_info 

 

gs 12639 

 

 

XML response message sent from the server to the client: 

 

 

 

 

firstname 

Garry 

 

 

lastname 

Sachs 

 

 

phonenumber 

01 l-732-632-6095 

 

 

faxnumber 

011 -732-632-6096 

 

 

e-mail 

gsachs @ mymail.com 

 

 

Transport and semantics 


The RPC protocol is completely independent of the transport protocols, 

i.e., the client can invoke RPC calls on the server irrespective of the 

transport protocol on which the RPC service runs. It deals only with the 

specifications and interpretations of messages and does not take into 

account the manner and way in which the messages are exchanged 

between the client and the server applications. Based on this 

independence from transport protocols, RPC protocol does not enforce 

any kind of semantics to the invocation or execution of a remote 

procedure. The semantics are explicitly declared by the transport protocol. 

Thus, client and server applications have to be aware of the transport 

protocol underneath RPC, as RPC service can run on a reliable protocol 

(such as TCP/IP) or an unreliable (UDP) protocol. 

Benefits of RPCs 

The biggest advantage of RPCs is their relative simplicity. Though the 

procedure is executed on a remote machine, it appears to the developer 

that it has been executed locally. Developers are removed from the 

complexities, which exist in other middleware solutions, most notably, 

distributed object models. 

Unlike the wild-west approach to APIs, comprehensive industry 

standards have been developed for RPCs. The most notable is the 

Distributed Computing Environment (DCE) standard created by the 

Open Software Foundation (OSF) in the 1980s. DCE is an industrystandard, 

vendor-neutral set of distributed computing technologies. The 

DCE standard for RPCs provides a complete distributed computing 

environment infrastructure including a security service to protect and 

control access to data, name services that make it easy to find distributed 

resources and a highly scalable model for organizing widely scattered 

users, services and data. 

Limitations of RPCs 

Though incredibly popular during the 80s and early 90s, RPCs have 

lost favor as a middleware solution to other technologies, such as


messaging and distributed objects. RPC is a procedural model, which 

primarily supports synchronous calls. In addition, RPC carries a 

significant amount of network overhead — it can be network hog. The 

many levels of services, which once made RPC appealing, also created 

the performance bottlenecks which make it very slow across large 

networks. 

3.4.3. Application oriented integration and B2Bi 

The applications to be integrated for B2Bi support different business 

lines of individual companies. This bag of application consist of a mix 

of home developed applications, third party solutions (such as ERP, 

CRM, SCM) and legacy systems. Their integration with the applications 

of the trading partners is much more than just making a remote method 

call or making one component talk to another remote component. 

It is a fairly straightforward task to integrate two applications 

developed by a single company using the same language and running 

on the same platform. However, integrating applications developed and 

maintained by different companies using different programming language 

and running on different platforms is an extremely daunting effort. 

For a successful implementation of this integration pattern, companies 

have to give away autonomy and develop applications in close 

cooperation with the partners. Making any changes to support new 

business logic or technical feature requires informing and coordinating 

with the partners, which makes this integration pattern the least flexible 

of all the integration patterns. Because of its inflexibility, which requires 

making coding changes for every small change in business flow, this 

integration pattern is also the most expensive in the long run. It creates 

dependency that can have a major impact on the business operations of 

the companies participating in B2Bi. 

Application oriented integration also requires making strict 

authentication checks before executing the function or method. The call 

to functions or methods can contain malicious code as it is usually 

made over the Internet. Furthermore, in order for the client programs to 

make RPCs or API calls, a company needs to open its firewall, which 

can pose security threats. Finally, A2A integration does not help a 

company to improve business processes.

3.5. Business Process Integration (BPI) 


Business process integration is a mechanism of integrating an 

organization's internal and external business processes with those of the 

business partners by sharing business information based on rules among 

diverse business systems. Business strategy and goals play an equally 

important role as technology in achieving successful B2Bi based on 

process integration. BPI aims to achieve integration based on business 

rules that help to improve the way business is done and make it more 

efficient. To achieve BPI-based B2Bi, companies have to go through a 

systematic and gradual implementation of business process management. 

BPI is more advanced than data oriented integration and application 

oriented integration since logic and reasoning of conducting business 

are included in this type of integration. It removes the limitations 

inherent in data integration or application integration types by focusing 

on the actual processes and not just the data. 

BPI is achieved through a much larger initiative involving the 

designing, modeling, automating, executing and monitoring of business 

processes. A single instance of BPI, i.e., a business process such as 

order management that has been integrated, may require several 

applications to be integrated at different levels and multiple steps of 

data transfer from one data source to another. 

3.5.1. Business process integration patterns 

B2B process integration can take place in various ways and at various 

levels of hierarchy and sophistication. The two most commonly used 

patterns of B2B process integration are closed process B2Bi or open 

process B2Bi, as described below. 

Closed process-based (private process) integration 

The closed process, also know as private process, based integration 

occurs when the organization manages processes internally and 

externalizes the key process activities only through the data exchange 

gateway (see Figure 3.25).


f 1 

* • 

Closed Business 

Process 

Closed Business ! 

Process I 

Company A Company B 

Figure 3.25. — Closed process-based integration 

The arrangement with closed process B2Bi is that the organization 

within its setup is able to track the status of business process activities 

internally. Appropriate and relevant business activities are shared by the 

partner organizations with the data exchange gateway. 

Open process-based (public process) integration 

The open process, also know as public process, based integration occurs 

when the organization creates the potential for sharing processes among 

multiple B2B corporate entities (see Figure 3.26). The management of 

processes is shared by the corporate entities, which requires the BPI 

products to be implemented within each organization. 

In an open process-based integration pattern, the processes internal 

to the organization continue to be internal and can only be viewed and 

reviewed internally. However, processes external to the organization are 

shared by the business partners and can be viewed and reviewed by all 

entities involved. 

Open process-based integration is more suitable for B2Bi applications. 

It gives higher flexibility to create and manage more complex and 

enhanced relationships among business partners.

— J 

Com pa MY A 

Figure 3.26. 

Open Business 

Process 


Company B 

Open process-based integration 

3.5.2. Business process integration and B2Bi 

BPI for B2B applications is based on shared processes, which represent 

an extension of data exchange capabilities to include agreements on 

multiple interdependent sets of messages. For example, two companies 

might agree to an order management process that specifies how 

acknowledgements are handled, the exception paths for order changes 

and backorders, or other logic specific to the relationship between 

buyer and seller. 

Business process oriented integration has several benefits for an 

organization and its trading partners. They include: 

• Opportunity to redesign existing business processes and take out any 

sort of latency involved. 

• Ability to design, model, automate and execute new business processes 

based on collaboration with the trading partners. 

• Capability to hide the intricacies of how each company handles 

internally the processing of data exchanged via messages based on 

standard business semantics. As long as the format and semantics of 

messages exchanged between companies remains the same, the 

underlying application responsible for processing and generating 

messages can change.


• Ability to monitor all the processes by getting real-time status 

information about their operational state. 

• Allows the reuse of source or target system despite changes in 

process model. The main feature of this approach is to allow the 

relevant information to be extracted from any source application, 

target application, or data store with the use of the routing feature in 

a BPI solution tool. This allows the model itself to be changed, due 

to process flow change or logic change, but without the change in the 

application(s) that are part of the process model. 

• Supports the flow of information amongst organizations involved in a 

community setting, providing a proactive system that shares important 

information in real-time. 

• Makes it possible not to share organizational sensitive information 

with the business partner community. 

Business process integration is made possible by a complete business 

process management suite, which includes a modeling tool, a business 

process engine and an administration tool. The modeling tool is used to 

graphically design and model business processes. The workflows 

generated depict processes of business activities in a graphical manner. 

They define how the information flows between applications with the 

logic that controls that flow. 

The engine provides the process integration technology and 

environment for executing business processes. It generates, processes 

and transforms the data which flows between cross-organization, disparate 

and autonomous applications, based on the business rules. It works in 

tandem with message oriented or transaction oriented middleware. The 

administration tool provides administration functionalities such as 

monitoring the business processes and may also include reporting 

functionality for generating various reports on the performance of 


BPI aims to achieve end-to-end EAI and B2B application integration 

while working with multi-organizational setup using various platforms, 

formats, technologies and processes. 

Note: Readers should refer to the chapter on business process 

management to obtain further details about BPI, BPM concepts and 

BPM systems.

3.6. Which Approach to Use for Your B2Bi 

Implementation? 


Companies wishing to venture into the world of integrated, collaborative 

and automated business face the following question: which integration 

type should we use to achieve B2Bi? 

3.6.1. Agreement among the trading partners 

B2Bi involves forming formal agreements among the trading partners to 

decide various factors involved in integration, such as level of integration, 

pattern of integration, scope of integration, data formats and XML 

standards. These agreements are dynamic in nature and are continuously 

changing with the business environment and needs. 

Some of the features of an agreement involved in a typical B2Bi 

implementation are as follows: 

• The scope of the agreement — whether the agreement is for a 

horizontal industry, vertical industry or between two companies or 

among a small group of companies and a major company dictating 

terms; 

• The type of integration method used — data oriented, business 

method oriented, portal oriented, or business process oriented; 

• The data formats used — the common data representation standards; 

• The business process definitions used — the definitions of the common 

business process used; 

• The communication protocol used — HTTP, FTP, e-mail, HOP, etc.; and 

• The security solutions — encryption, digital certificates, VPNs, digital 

signatures. 

All these features of an agreement play a very important role in 

determining the integration pattern used to achieve the final goal of 

integration. 

3.6.2. Your integration goals 

Each integration pattern discussed here has its own merits and 

shortcomings. There are several criteria that can guide you to determine


which approach best suits your integration goals. The most important 

ones are: 

• Will the integration be real-time? 

• What is the level of complexity of a given solution? 

• What is the degree of synchronization achieved in the integration? 

• Is the solution robust and scalable enough to handle your integration 

needs? 

• Is the solution flexible enough to adapt to your company's business 

processes? 

• What is the level of autonomy or independence that your company 

will have in implementing the solution? 

• How close the participating companies will have to work in order to 

achieve integration based on the solution? 

Figure 3.27 shows the different modes of integration and the level of 

synchronization achieved in using each one of them. 

To achieve B2Bi, your company will have to adopt one or more of 

the integration patterns discussed in this chapter. Irrespective of the 

integration pattern or a combination of multiple patterns that you employ 

for B2Bi, the final goal is to achieve real-time, secured access to 

internal corporate and external (suppliers, partners and customers) data, 

which allows dynamic collaboration. The integration strategy should be 

in line with your company's business and technology environments and 

short-term and long-term business goals. 

*Asynchronous Replication (Delayed) 

IfData Warehouses 

Data Marts 

•Transient Data Sources 

Staged 

• Asynchronous RPCs 

•Asynchronous API Calls 

Message Queuing 

• Message Br oka's 

f-Publish and Subscribe 

Non-real-time 

Virtual Data Warehouses 

• Synchronous Replication 

f Multi-database Servers 

• Databas e Acces s APIs 

Real-time (Data Integration) 

• Synchronous RPCs 

• Synchronous API Calls 

• Object Request Brokers 

• TP Monitors 

Real-time (Application Integration) 

Figure 3.27. — Level of synchronization in different types of integration



There are several integration patterns that a company can use to achieve 

B2Bi. The choice as to which integration pattern to choose depends on 

the agreement with the trading partners, existing infrastructure and 

integration goals, such as level of synchronization and degree of 

autonomy desired. 

Data oriented integration provides data access interface abstraction. 

It always involves data sharing and can result in communication between 

an application and a data source or a data source to another data source. 

It can be schedule or event-driven, based on the type of integration 

pattern used, such as synchronous replication or asynchronous replication, 

data warehouses or virtual data warehouses. The most common solution 

based on data oriented integration uses an ETL server. 

Application oriented integration involves API or RPC communication 

between application components, which may or may not involve data. 

Since cross-organization applications have to be integrated directly in 

this pattern, the participating companies have to work very closely to 

jointly develop the applications. Companies have less autonomy in this 

integration pattern, thus making it the least suitable for most B2Bi 

implementations. However, this type of integration is synchronous in 

nature, i.e., the data is shared on a real-time basis. 

Portal oriented integration is a quick way for small to medium size 

companies to provide data access to customers and trading partners 

through a Web-based interface. 

Business process oriented integration provides process interface 

abstraction that maintains the integrity of business rules. This integration 

type is being used by companies more and more as it not only aims at 

integration, but also at making the business processes of a company 

efficient by eliminating latency. Moreover, this integration type gives 

companies complete autonomy in terms of how they want to conduct 

their business, as long as they are able to communicate with their 

trading partners based on certain pre-determined standards.

Chapter 4 

Enterprise Application 

Integration (EAI) 


Integration of internal applications is the single most important element 

of B2B integration which can make a company's B2Bi implementation 

a success or a failure. 

In this chapter, we will explore the different enterprise-wide 

applications such as customer relationship management (CRM), enterprise 

resource planning (ERP) and legacy systems. We will explain to you 

the convergence and divergence of enterprise application integration 

and business-to-business integration along with case studies. To give 

you information about the commercially available softwares for EAI, 

we have presented discussion of the major EAI solutions. 

96

4.1. Today's Enterprise 

Enterprise Application Integration (EAI) 97 

Today, an average Fortune 500 company may have 50 or more internal 

business applications deployed in multiple countries, different platforms 

and sometimes even on different versions of the same technology. Such 

large enterprises have small enterprises within themselves in the form 

of autonomous groups, with each one of them having its own technology, 

business priorities and preferences. 

The information technology environment in companies is extremely 

dynamic as they adopt the latest and the best-of-breed software solutions 

that can help them in beating the competition. However, no single 

vendor can provide all these solutions. Again, the solution from each 

vendor may have different hardware, platform and database requirements, 

which results in the implementation of multiple physically separate 

systems. 

As companies move in the direction of B2Bi, they will first have to 

look inward to their own internal systems, applications and processes. 

Several business processes span across multiple internal applications. 

These applications must be able to communicate before a company can 

effectively e-communicate with the outside world. 

4.2. What is EAI? 

Most companies have inherited an environment of disparate legacy 

systems, applications, processes and data sources that typically interact 

by a maze of interconnections that are poorly documented and expensive 

to maintain. Additional problems arise from market consolidation in the 

digital age. Mergers and acquisitions of companies today can increase 

the complexity of system integration exponentially. 

As the need to meet increasing customer expectations continues to 

rise, companies are forced to link their disparate systems to improve 

productivity, efficiency, and, ultimately, customer satisfaction. 

The need for IT systems to communicate within an organization led 

to the evolution of EAI. EAI is the process of creating an integrated 

infrastructure for linking disparate systems, applications and data sources 

across the corporate enterprise.


Custom Packaged BHJIMM Legacy Network 

Applications Applications DataBase* Systems Technology 

Adapter Adapter Adapter Adapter Adapter 

The EAI Platform 

Figure 4.1. — The EAI platform 

EAI processes and tools help companies evolve to e-business by 

creating an integrated infrastructure to connect existing legacy systems 

and back-office applications with the Internet, allowing an organization 

to move and share information and data across all boundaries (see 

Figure 4.1). 

4.3. Where Did Things Go Wrong? 

Twenty to 30 years ago, information systems were relatively simple in 

makeup: there was the mainframe. The mainframe served its purpose 

admirably, providing an inherently integrated system. The minicomputer, 

often of a UNIX flavor, arrived soon after. 

The late 80s gave rise to distributed systems. With their rise came a 

strong move within companies to departmentalized information systems. 

The new distributed systems were generally based on UNIX and 

Windows technologies, the latter of which introduced the graphical user 

interface to the business world. 

The migration to departmentalized distributed computing was 

motivated by several factors, including: 

• The desire to implement graphical user interfaces, which were not 

yet possible using mainframe 'green screens'; 

• The perceived (often wrongly) notion that distributed client-server 

systems were cheaper and easier to implement and maintain; 

• The need for departmental executives to build fiefdoms to obtain 

personal advancement within the corporation; and 

• The ability of out-of-control IT departments to implement the latest 

technologies into the market without giving proper consideration to 

return on investment or revenue.

Internal Applications Jf"**"*"^ 

(Java, C, C++) "#-«w_ 

Enterprise Portal 

Application 

Financial System 


ERP System 

SCM System 

Figure 4.2. — The enterprise maze 

m M cv.«4-=.« 

Databases 

Legacy System 

The segmentation of information systems was exacerbated with the 

introduction of commercial off-the-shelf applications such as ERP and 

CRM. Early on, these systems were designed as self-contained 'blackbox' 

systems with little or no means for accessing internal data or 

processes. Though many of these applications now provide better access 

to their underlying data and business logic, integrating these systems 

with other systems within the enterprise is still a challenge. 

Each node in Figure 4.2 maintains its own data, which may be 

shared among the nodes. Sharing of this data has been typically 

accomplished using data transfer methods including batch processes and 

data import/export jobs. Since the data of one node is not available in 

real-time to other nodes, the latter cannot analyze and make decisions 

while a transaction is being processed at the former. This is one of the 

major factors that justify EAI. In fact, the very origin of EAI can be 

linked to the need for providing a full duplex, bi-directional solution to 

share seamlessly and exchange data between ERP, CRM, SCM, databases, 

data warehouses and other important internal systems within the company 

(see Figure 4.3).


Internal Applications 

(Java, Q C++) 

Enterprise Portal 

Application 

Financial System 

4.4. Benefits of EAI 

ERP System 

CRM System 

EAI Solution Databases 

SCM System 

Figure 4.3. — The EAI solution 

Legacy System 

EAI is not an out-of-the-box solution, but rather an ongoing process of 

creating a flexible, standardized enterprise infrastructure that allows 

new IT-based applications and business processes to be easily and 

efficiently deployed. The new infrastructure allows applications 

throughout an enterprise to seamlessly communicate with one another 

in a real-time manner. 

When implemented properly, EAI can provide many benefits 

including: 

• Enabling an organization to link legacy systems with new systems 

such as CRM and ERP to take advantage of electronic commerce 

opportunities; 

• Helping companies realize the benefits touted from business 

acquisitions and mergers; 

• Improving the speed for bringing products to market, systems to 

implementation and new business units on-line; 

• Allowing companies to quickly react to changes in the business 

model; and 

• Enabling companies to take advantage of changes in the industry and 

technology.


HOW ORACLE RE-ARCHITECTS ITS GLOBAL 

INFRASTRUCTURE INTO A CENTRALIZED 

E-BUSINESS ARCHITECTURE 

Oracle Corporation, like other large corporations had built a huge, 

distributed, worldwide culture based upon a client/server-computing 

infrastructure. For example, the company had 60 disparate financial 

systems in 60 different countries and 120 e-mail databases globally. 

Oracle was spending $600 million annually on global IT operating 

costs and the support of 1500 IT personnel to maintain them. The 

profit margins of the company were only 20% rather than 60% that 

successful software companies usually experience. 

Through a closer scrutiny of their business processes, the 

management realized that the 60 independent profit centers of the 

company created expensive redundancy uncontrolled spending, lower 

productivity and huge maintenance bills. The company was spending 

uncontrollably, adding more databases, applications and client/server 

infrastructure to support the phenomenal growth, while exponentially 

increasing the complexity. 

Realizing this, the company began a rather tough, but rewarding 

journey of re-architecting its systems into a centralized e-business 

model that dramatically reduced maintenance on the desktops, 

inherently eliminated unnecessary servers and databases and greatly 

reduced IT and maintenance cost. For example, Oracle consolidated 

97 e-mail servers and 120 databases into 4 servers running 4 databases 

and implemented a 'direct standards' model that allows it to maintain 

and update centralized applications worldwide from a single, 

centralized data center. Through this re-architecture of its systems, 

Oracle has reduced its operating budgets from $600 million to $440 

million annually. 

Source: Condensed from keep It Simple: How Oracle Consolidated Its Global 

Infrastructure into a Centralized E-Business Architecture, Oracle White Paper. 

4.4.1. A word of caution 

Unfortunately, most IT shortcomings exist even today. One only needs 

to substitute the term 'Web-based' for 'client-server' to see this. The


situation has never been more apparent than with the swift rise, and 

even swifter fall, of the Internet dot-coms. Both old and new economy 

companies rushed into the 'sexiest' Internet technologies without any 

regard for ROI, revenue or shareholder value. Today, with one eye on 

the enormous implementation costs and another eye on the failure of the 

dot-coms, many companies have taken a more cautious approach. As 

the saying goes: "the more things change, the more they stay the same." 

The benefits of EAI are great, but so are the pitfalls, if one does not 

approach it in a systematic, cost-effective manner. 

4.5. Types of EAI 

EAI solutions can take on many forms and exist at many levels. The 

appropriate level of EAI can be dependent on many factors including 

company size, company industry, integration/project complexity and 

budget. 

There are three types of middleware solutions to EAI: 

• User Interface Integration; 

• Data Integration; 

• Function or Method Integration; and 

• Business Method Integration. 

A brief overview of each of these levels of EAI include: 

4.5.1. User interface integration (Refacing) 

Refacing is the process of replacing the terminal screens of legacy 

systems and the graphical interfaces of PCs with one standardized 

interface, typically browser-based. Generally, the functionality of terminal 

screens applications can be mapped on a one-to-one basis with a 

browser-based graphical user interface. The new presentation layer is 

integrated with the existing business logic of the legacy systems. 

Enterprise business portals may also be considered a sophisticated 

refacing solution. A business portal consolidates the presentation of 

multiple applications into one customizable browser-based interface. A


portal can provide a unified HTML interface to legacy systems, CRM 

and ERP applications, messaging services, external Websites, etc. An 

example of a popular portal site is my.Yahoo.com, which consolidates 

news, weather, sports and e-mail, among other things, into a single 

unified Website. 

4.5.2. Data integration 

Data integration occurs at the database and data source level within an 

organization. The integration is achieved by migrating data from one 

data source to another. Most companies today employ some form of 

data integration to achieve a primitive, yet necessary EAI model. 

There are a bevy of data replication and middleware tools to facilitate 

data transfer between data sources in both real-time and batch modes. 

Some data integration methods include: 

• Batch Transfer; 

• Data Union; and 

• Data Replication. 

Data integration is the most prevalent form of EAI in existence 

today. Data integration solutions are inexpensive and they often achieve 

the desired results. One of the biggest problems with data integration is 

that the business logic usually exists only within the primary system, 

limiting real-time transactional capabilities. 

4.5.3. Function or method integration 

Function or method integration involves the direct and rigid applicationto-application 

(A2A) integration of cross-platform applications over a 

network. It can range from custom code (COBOL, C++, Java), to 

application programming interfaces (APIs), to remote procedure calls 

(RPCs), to distributed middleware such as TP monitors, distributed 

objects, common object request broker architecture (CORBA), Java 

remote method invocation (RMI), message oriented middleware (MOM) 

and Web services (see Figure 4.4).


iai 

1 « 

i 

Raquast 

API 

Java RMI 

CORBA 

DCOM 

RPC 

Web Services 

Response 


Figure 4.4. — Function or method integration 

Function or method oriented integration is primarily synchronous in 

nature, that is, it's based on request/reply interactions between the client 

(requesting program) and the server (responding program). 


While data integration has proved a popular form of EAI, it can 

present problems from a security, data integrity and business process 

perspective. A vast majority of data within an organization is accessed 

and maintained through business logic. The business logic applies and 

enforces the required business rules, processes and security for the 

underlying data. 

Business process integration (BPI) occurs at the business process or 

method level, which may span multiple applications (see Figure 4.5). 

BPI is often characterized by the use of advanced middleware, which 

standardizes and controls the flow of information through a bus or 

hub-and-spoke framework. 

Business process integration can range from custom code (COBOL, 

C++, Java) to application programming interfaces (APIs) to distributed 

middleware such as TP monitors, distributed objects and message 

oriented middleware (MOM).



Figure 4.5. — Business process integration 

4.6. Types of Enterprise Systems 

To understand EAI, one must first understand the types of application 

frameworks and architectures which exist with an organization. EAI can 

involve legacy systems, ERP packages, CRM systems, SCM systems 

and other applications. 

4.6.1. Legacy systems 

The term 'legacy system' typically refers to large mainframe, minicomputer 

and UNIX systems that use terminal-based (thin) clients. 

These systems are comprised of mission-critical business applications, 

databases and file management capabilities, typically contained within 

one central operating environment. There are estimates that upwards of 

70% of corporate data still reside on legacy systems. 

Today it seems that those who profit from EAI have their own 

definitions of what a legacy system is. Some have expanded the term 

'legacy system' to refer to any existing application that uses languages, 

platforms, or techniques that are older than the current technology. 

Contrary to popular belief, legacy systems still provide the majority 

of the back-office processing capability for most Fortune 500 companies. 

These systems can typically support a very large user base and provide 

processing power still unmatched by any distributed system. Advances


in middleware and integration technologies have made legacy systems 

accessible to today's distributed systems. Consequently, companies are 

now leveraging the capabilities of their legacy systems by integrating 

them as the backbone of their new B2B infrastructure. 

4.6.2. Client/server systems 

The advent of the graphical user interface and the workstation gave rise 

to a new architectural model comprised of a 'fat' client and a database 

server. These systems were made possible through the proliferation of 

workstations running Windows or UNIX and the rise of distributed 

database vendors such as Oracle, Sybase and Informix. 

For the first time, organizational departments within a company 

could implement and maintain their own information systems. These 

new 'silo' systems allowed managers to exercise more control over 

their data. 

Beyond the departmental information system, client/server systems 

produced many other benefits. The advent of the graphical interface 

gave rise to powerful business tools, such as spreadsheets and word 

processors, creating a much more productive office worker. 

These client/server systems also created a technology savvy 

generation. Computing technologies and architectures were no longer 

confined to the IS department in a closely guarded server or mainframe 

room at corporate headquarters. 

Though distributed client/server systems contributed to the EAI 'mess' 

found in most companies today, it created a new competitive, innovative 

technological environment which has fueled the productivity and 

efficiency boom during the past decade. 

4.6.3. Enterprise Resource Planning (ERP) 

Enterprise resource planning (ERP) arrived on the scene in the early 

90s and has become a core element in the enterprise infrastructure. ERP 

is a software solution that addresses the needs of an entire enterprise. It 

takes a process-level view of an organization and attempts to tightly 

integrate all its functions.


The efficiency, and ultimately, the success of an enterprise today 

depends on the immediate flow of information across the complete 

supply chain. To this end, ERP promises to replace multiple, disparate 

silo systems with one enterprise environment. Today's modern ERP 

systems enable companies to standardize business processes across the 

enterprise including sales, accounts receivable, engineering, planning, 

inventory management, accounts payable, quality management, 

production, distribution planning and external transportation. 

History of ERP 

ERP initially grew from the needs of the manufacturing industry. The 

focus of manufacturing systems in the 1960s was on inventory control. 

Most of the software packages were 'homegrown' and designed to 

handle inventory based on the traditional inventory models of the time. 

In the 1970s the focus shifted to MRP (Material Requirement Planning) 

systems that translated the master schedule built for the end items into 

time-phased net requirements for the sub-assemblies, components and 

raw materials planning and procurement. 

In the 1980s, with the advent of the just-in-time inventory model, 

MRP evolved to MRP-II which extended material planning to the 

shop floor and distribution management activities. In the early 1990s, 

MRP-II was further extended to cover areas such as engineering, finance, 

human resources and project management — essentially any process 

across the enterprise. Hence, the birth of enterprise resource planning. 

ERP implementation 

The implications to existing business processes must be assessed before 

implementing an ERP solution. The traditional approach has been to 

conduct a comprehensive business process reengineering (BPR) analysis 

prior to taking up ERP. The BPR process should identify areas for 

process improvement in addition to high-level integration and 

customization requirements. 

The leaders in the ERP marketplace include SAP AG (SAP R/3), 

PeopleSoft, JD Edwards, Oracle, BaaN Infosystems (BaaN IV), Ramco 

Systems (Marshal) and QAD (MFG/PRO). SAP is, by far, the dominant


leader in the ERP market. According to AMR Research, the top 

five ERP vendors, SAP America, Oracle Corporation, Peoplesoft, Inc., 

JD Edwards & Company and Baan International, accounted for 64 

percent of the total ERP market revenue in 2000. Oracle, a newcomer 

to the ERP marketplace, has quickly been making inroads. 

Each vendor's product can automate a wide array of organizational 

functions and processes, but they are generally focused on financials/ 

accounting, manufacturing and human resources. Some modules typically 

offered through the most popular ERP products include: 

• Production Planning; 

• Materials Management; 

• Plant Maintenance and Service Management; 

• Quality Management; 

• Financial Accounting; 

• Human Resource Management; 

• Business Information Warehouse; 

• Treasury; 

• Controlling; 

• Enterprise Consulting; 

• Investment Management; and 

• Sales & Distribution. 

The decision to implement an ERP system should be considered 

carefully and planned even more carefully. Often touted in the past as 

an 'out-of-the-box' solution, ERP is hardly that. A CD-ROM and some 

training classes cannot fix the problems of a dysfunctional organization. 

But, when implemented properly, ERP can provide a significant 

competitive advantage. 

Evolution of ERP II 

The role of ERP continues to expand, not just across an enterprise, but 

across multiple enterprises. This rapid evolution of ERP has led to a 

new vision appropriately called ERP II. The major difference between 

ERP and ERP II involves a practice termed as collaborative commerce. 

According to the Gartner Group, collaborative commerce enables business 

partners from multiple companies to exchange information posted


on e-commerce exchanges. For example, companies can develop new 

products with their suppliers by sharing each other's data across online 

marketplaces. Collaborative commerce also enables organizations to 

find new partners to solve one-off design problems. 

Unlike old-style ERP, ERP II will cut across all business processes, 

such as customer relationship management (CRM), as well as traditional 

functions including finance and human resource management. ERP II 

will also be applicable to all industries, not just the finance, manufacturing 

and distribution sectors that were the original focus of ERP. 

ERP integration 

Before we start discussion about ERP integration, it is of utmost 

importance to understand clearly what ERP is not. ERP is not the 

nirvana of a company's integration needs — it is just another application 

that has to be integrated through EAI. Secondly, no ERP will provide 

all functionalities to support every business aspect of a company — 

thus there will always be multiple applications apart from ERP. There 

will be a need for an adapter or interface to communicate between ERP 

and other applications. 

ERP integration can be done in multiple ways, such as developing 

in-house connector components, using the APIs provided by the ERP 

vendors, configuring third party adapters or using XML-based messaging 

for extracting and sharing data between ERP and other internal 

applications. 

SAP, the most popular ERP package, supports integration in the 

following ways: 

BAPI-API Oriented Integration — SAP R/3 system provides a business 

framework consisting of business objects (which represent business 

objects such as purchase orders, G/L accounts, employees), which are 

made available to the external applications through BAPI (Business 

Application Programming Interfaces). BAPIs are object-oriented views 

of R/3 applications and data. BAPIs enable synchronous integration 

between the SAP R/3 system and external systems. Figure 4.6 below 

depicts multiple ways in which BAPIs can be invoked through other 

programs.


Source: SAP, AG 

SAP R/3 Server 

i 

[ B us ineas iO bj«ct|~—f BAP: 

A BAP: 

r 

Business €*bi»st Regwsltery 

fitoJeefc-OriMtlei:' Mm®m 

Function Module! 

(RFC Capable) 

Function Modulej 

(RFC Capable) 

Function Modulej 

(RFC Capable) 

Fitnttiort ftuJMttr' 

• HFC A«*s* 

Figure 4.6. — BAPI and RFC enabled integration 

RFC-Method Oriented Integration — SAP provides support for remote 

function calls (RFCs), which enable synchronous communication between 

R/3 and non-SAP systems, or even different modules of the same R/3 

system. RFCs hide the implementation details of the function modules 

from the external applications and manage the communication process, 

error handling and parameter transfer. 

IDocs-Data Oriented Integration — SAP provides a mechanism to 

exchange data to and from R/3 systems in file formats through 

Intermediate documents (IDocs), which act like containers of that data. 

This type of integration is asynchronous in nature and is useful for 

transferring large amount of data. IDocs contain a header and segments 

of data. SAP has defined templates for all the possible IDocs that 

represent business documents of R/3 system like purchase orders. 

XML-Message Oriented Integration — SAP Business Connector 

enables exchange of R/3 system business documents as XML-based 

messages with other SAP and non-SAP systems (see Figure 4.7). 

Messages are formatted in XML (based on the industry standards


Figure 4.7. — SAP business connector 

like ebXML, RosettaNet) and delivered securely via HTTP to other 

applications that have subscribed to the message. These applications 

can be located on the same server, or over the Internet. SAP Business 

Connector also supports BAPIs and Idocs. All the business interfaces 

supported by SAP are published as XML schemas in the SAP Interface 

Repository. 

4.6.4. Customer relationship management (CRM) 

Customer relationship management (CRM) is not a new concept. For 

decades, companies have strived to be 'customer-focused'. What is new 

is the technology that enables large, faceless corporations to know their 

customers at a more intimate level. The Gartner Group defines CRM as 

a customer-focused business strategy designed to optimize profitability, 

revenue and customer satisfaction. CRM is designed to understand and 

anticipate the needs of the current and potential customer base. It is all 

about managing the customer experience and providing a single integrated 

view of the customer at all touch-points.


CRM should focus primarily on process and methodology, not 

technology, though technology is quickly becoming the enabler for 

methodology. 

Some of the traditional business processes which CRM products 

facilitate include sales, marketing, call center and helpdesk activities. 

The benefits generated from a successful CRM implementation include: 

• More effective customer acquisition and retention; 

• Comprehensive view of all customer interactions through all access 

channels; 

• Optimization of each customer interaction for increased business 

opportunities; 

• Anytime, anywhere access to customer and enterprise information; 

• Effective use of employee resources; 

• Increased responsiveness to customers; and 

• Greater operational efficiency across the entire enterprise. 

The growth of CRM is still going strong. The Aberdeen Group 

estimates that the CRM market generated $7.8 billion in revenue from 

software packages, software-vendor licenses, integration services and 

peripheral and hardware sales for 1999, with CRM software sales 

making up $3.8 billion of that total. It is estimated that this market will 

grow to $9.4 billion by 2002, with CRM sales software and customerservice 

software growing the fastest. Another study released by IDC 

estimates that the customer relationship management services market 

will rise to $148.0 billion in 2005 from 61.0 billion in 2001, representing 

a compound annual growth rate (CAGR) of 25.0 percent and "far 

exceeding" the overall IT services market. 

At the same time, Meta Group estimates that between 55% and 75% 

of CRM implementations will fail to meet their objectives. Like ERP, 

CRM impacts an organization at many levels. If not planned for and 

executed properly, a CRM implementation can have catastrophic 

consequences on a company's bottom-line. 

CRM and data warehouses 

An integral component of CRM is a data warehouse which allows 

companies to gather and use an ever-growing data repository about

Buyers 


to L m 1 _ 

Figure 4.8. — Data warehouse works in conjunction with CRM application 

product use and marketplace trends (see Figure 4.8). Data analysis and 

business intelligence tools are applied against the data warehouse to 

identify customer trends and needs. Data warehouses used in conjunction 

with business intelligence tools allow CRM products to: 

• Measure the effectiveness of sales and marketing activities and return 

on investment of the system; 

• Assess sales strategy based on information such as discount sales 

analysis and pipeline status; 

• Evaluate customer service performance; and 

• Analyze profitability by customer or channel. 

4.6.5. eCRM 

Person 

-* Mail hr- 

Phone 

Web l*-> 

Fax 

-* WAP I* 

Internal 

Application* 

uaia 

Warehouse 

Internal 

Data Sources 

Person 

-* Mat! 

Phone 

The rise of e-business has also given rise to electronic CRM (eCRM). 

eCRM provides companies with a means to conduct interactive, 

personalized and relevant communications with customers across both 

traditional channels and the Internet. eCRM includes eMarketing, eSales, 

eCare, eWarehousing and eProfiling (see Figure 4.9). According to the 

META Group, the eCRM software market is expected to grow 42% this 

year, reaching $10 billion by 2002. 

Web 

Fax 

~* WAP H- 

•a 

Suppliers 

Tfft


eSales 

^Marketing 

Figure 4.9. — The circle of eCRM 

eWarehousing 

eProfiling 

The role of eCRM is an ever-expanding one, but is generally 

characterized as follows: 

• eCRM extends CRM by providing anytime, anywhere, real time 

access to customer information via the Internet/Web and mobile 

devices. Most CRM vendors can now deliver information using open 

communication standards such as HTML, WAP and XML for 

delivering information to browsers or mobile devices. eCRM products 

can also provide an out-of-the-box portal solution to users, which 

creates a single browser-based entry point into the CRM system. 

• eCRM integrates traditional CRM with legacy, back-office and other 

e-business applications, including ERP and SCM. CRM vendors (as 

well as ERP vendors) are working hard not only to integrate their 

products with new e-business frameworks, but also to expand their 

own offerings and product lines to deliver the complete e-solution. 

• CRM can capture a Web-surfer's digital trail to understand that 

user's buying patterns. Through eCRM, a customer's patterns are 

captured to provide a personalized experience during future visits. 

Personalization enables an e-business to offer products uniquely 

relevant to the individual visitor, creating a Web experience tailored 

to individual's tastes.


The leaders in the CRM software market include Siebel Systems, 

Vantive, PeopleSoft and Clarify. The lines between CRM and ERP are 

quickly becoming blurred as vendors from traditional ERP and CRM 

markets cross over to each other's markets in an effort to create the 

complete, enterprise e-business solution. 

4.6.6. CRM and EAI 

The CRM system is based on integration hub-and-spoke architecture, 

rather than a point-to-point based architecture. The integration hub is 

the source of all business data. But, how does the integration hub get its 

data? The answer is through EAI, which retrieves, transforms and feeds 

the CRM system with the data from multiple applications like SCM, 

ERP and legacy systems. 

4.6.7. Supply Chain Management (SCM) 

SCM system integrates forecasting, planning and execution, thereby 

providing complete visibility across the supply chain. 

We have discussed the characteristics and features of SCM systems 

at great length in the chapter on supply chain management. 

4.7. Leading EAI Solutions 

Although there are several companies that provide EAI solutions, in this 

section we will discuss only the prominent ones. 

4.7.1. BEA eLink 

The BEA eLink is a suite of enterprise application integration (EAI) 

products that includes BEA Data Integration Option — for data 

normalization, transformation and routing, BEA Business Process 

Option — for process automation and BEA eLink Adapters for 

enterprise applications, mainframes and other environments — for 

application connectivity.


Business Model 

Data Model 

Databases 

MVS acs / IMS 

SNA, TCP/IP 

Business Process 

Option 

Information 

Integrator 

BEA eLink Foundation 

ERP 

SAP, PeopleSoft, 

Qrade, etc. 

Legacy, 

Custom 

* 

CRM 

Clarify, Siebel, 

etc. 

»f • 

Billing 

Kenan, Portal, 

etc. 

Figure 4.10. — BEA eLink enabling EAI 

Electronic 

Services 

According to the BEA eLink product data sheet, as of this writing, 

the following adapters are made available by BEA (see Figure 4.10): 

• Customer resource management (CRM) applications: Vantive, Siebel, 

Clarify; 

• Enterprise resource planning (ERP) applications: SAP R/3, PeopleSoft, 

Oracle; 

• Mainframe applications: CICS, IMS, any SNA peer; Unisys OS 

2200, Unisys MCP/AS, or any system that supports Open Group 

XATMI over OSI TP; 

• Billing applications: Portal, Kenan; 

• Internet and integration adapters: BEA eLink Adapter for Broadvision, 

BEA eLink Adapter for XML and BEA eLink Adapter for MQSeries; 

and 

• Integration with databases: Oracle, Informix, Sybase, etc. 

4.7.2. TIBCO ActiveEnterprise 

The TIBCO ActiveEnterprise consists of several products that enable 

EAI. These products are (see Figure 4.11):


TIB/In Con cert 

TIB/Integration Manager 

TIB/Message 

Broker 

f, ,,;•• 

Figure 4.11. — TIBCO's ActiveEnterprise platform 

TIB/InConcert — automates the workflow of customer-oriented 

processes. 

TIB/IntegrationManager — defines and manages automated business 

processes that span multiple applications and transactions. 

TIB/MessageBroker — performs automated message transformation and 

business object mapping. 

TIB/Adapters — integrates off-the-shelf applications and databases. 

Each adapter integrates with one or multiple interfaces provided by the 

legacy, CRM, ERP and other applications. 

Adapters simplify the whole process of adding a new application in an 

enterprise, as long as it implements the ActiveEnterprise data model. 

The new application will be integrated seamlessly with every other 

application, database and network that is a part of the ActiveEnterprise 

platform. This specifies a very important point — through the use of 

adapters, applications just have to publish the data to the network. 

Other complex actions such as message transformation and business 

process automation are completely hidden from the individual applications. 

According to the data sheet provided by TIBCO, TIB/Adapters are 

available for many applications and platforms including SAP R/3, Siebel, 

Peoplesoft, Vantive, Clarify, Lotus Notes, Portal Infranet, Kenan and 

others. TIB/Adapters for Network Technologies are available for COM,


CORBA, MSMQ and MQSeries. TIB/Adapters for RDBMS are available 

for Oracle, MS SQL and Sybase. 

TIB/Rendezvous — forms the foundation of ActiveEnterprise by 

providing a very advanced and flexible messaging system. 

TIB/Hawk — provides comprehensive system monitoring and 

management capabilities. 

4.7.3. IBM — WebSphere MQ integrator 

WebSphere MQ Integrator enables EAI through a combination of business 

rules and message formatting. It contains MQSeries — for messaging 

and queuing, NEONrules — for evaluation of the content of messages 

and routing them based on the application rules, NEONformatter — for 

transforming the data in appropriate format as required by the receiving 

application and NEON Adapters — an adapter for each application that 

handles the communications with the application and passes metadata 

to the NEONformatter. 

NEON Adapters connect WebSphere MQ with applications such as 

SAP R/3, Peoplesoft, Oracle, JDEdwards, Siebel, Broadvision and i2 and 

support industry standards such as EDI/XML, SWIFT message format 

and FIX message format library. 

GARTMORE ENTERS A NEW GENERATION OF 

TRADE PROCESSING 

Straight Through to the Benefits 

For over thirty years, Gartmore Investment Management Pic — one 

of the UK's leading investment management companies — has been 

managing money for corporate, institutional and private investors. 

Since 30th September 2000, it has managed funds worth more than 

54 billion Pounds Sterling, covering the world's major equity, bond 

and currency markets. 

To maintain its investment management leadership, Gartmore has 

embarked on a strategy to exploit the latest straight-through processing 

Continue on page 119



techniques. By implementing a resilient EAI solution, Gartmore has 

been able to automate, streamline and accelerate the exchange of 

transaction information between the internal applications used in 

generating and executing trades. 

A 'Landmark' Achievement 

With a distributed technology environment — spanning Sun Solaris, 

OS/400 and NT operating platforms, as well as Sybase, Oracle and 

SQL Server databases — Gartmore needed a strategic EAI solution 

capable of delivering accurate and reliable file sharing across all 

platforms. 

For this reason, it chose to implement a backbone infrastructure, 

comprising IBM MQSeries message oriented middleware combined 

with enableNet Data Integrator software from IBM Business Partner 

CommerceQuest. 

Gartmore implemented this solution initially to support, the 

installation of a new financial order management and execution 

package called Landmark. This system replaced the existing order 

process, which involved handwritten deal tickets passed to input 

clerks by dealers to be loaded on Paladign — Gartmore's existing 

AS/400-based back-office investment accounting system. To fully 

exploit the benefits of Landmark, Gartmore realized that it needed to 

integrate it seamlessly with Paladign. 

Having experimented with FTP and other file transfer mechanisms, 

Gartmore concluded that it needed a far more resilient and reliable 

solution for exchanging data between Landmark and Paladign. 

MQSeries proved to be the answer. It is universally accepted as a 

rehable and stable messaging product and its cross-platform capabilities 

and guaranteed delivery mechanisms were precisely the attributes 

Gartmore required to realize its STP vision. 

Gartmore then chose enableNet Data Integrator as a complementary 

EAI solution and discovered that the two products played to each 

other's strengths perfectly. That's because enableNet Data Integrator 

has been specially developed to employ MQSeries' message queuing 

technology as its underlying communication infrastructure. Through 




the use of asynchronous communication, storage queues and other 

coordination devices, MQSeries effectively maximizes reliability of 

data delivery, even in a connectionless state and during network 

failures and outages. What enableNet Data Integrator adds is an 

additional layer of data integration, coordination, reliability and 

integrity, providing an EAI infrastructure that is unmatched for its 

fail-safe reliability and security. enableNet Data Integrator is enabling 

Gartmore to achieve comprehensive audit control, tracking every 

single file across the network. 

The new EAI solution also takes the pain out of overnight batch 

processing. No matter what happens with the network, enableNet 

Data Integrator simply continues from where it left off. Besides 

assuring the integrity of data, the business isn't impacted by 

unnecessary delays and dealer screens are updated quickly and 

efficiently. 

Higher Trade Volumes — Faster and More Accurate 

In terms of business benefits, Gartmore is delighted with the results 

of its new order generation and execution management process. They 

handle around 35% more trades in a very efficient and timely fashion 

with the new system. Information is captured more accurately at the 

point of generation and processed smoothly and rapidly. 

Valuable administration resources are no longer required for 

re-keying data and the burdens on back-office staff have also been 

reduced. 

Since implementation, Gartmore has employed its EAI hub to 

integrate a new Sun Solaris-based SmartStream reconciliation package 

with the AS/400 accounting system. And, in the future too, with 

MQSeries at the heart of the hub, Gartmore knows that it can achieve 

rapid deployment of new applications, without having to worry about 

complex integration issues. 

Source: Condensed from Mimesweeper's case study on Gartmore Mimesweeper.com

4.8. Convergence of EAI and B2Bi 


The lines between B2Bi and EAI are quickly becoming blurred. 

Traditional EAI middleware has been characterized by the integration 

of back-office applications and front-office activities. But many of the 

traditional EAI services are also a necessity in many of today's B2Bi 

models; and EAI middleware vendors have been quick to capitalize on 

this fact. The entire EAI, B2Bi and enterprise software marketplace is 

converging, merging and morphing at a rapid pace. 

This convergence is most apparent in the latest generation of 

middleware products where B2Bi and EAI software share many common 

features, including: 

• Data transformation; 

• Use of application-specific adapters and APIs; 

• Messaging; 

• Intelligent routing; and 

• Workflow/process management. 

E-business software vendors such as IBM and BEA are combining 

EAI and B2Bi services under one product. These vendors are taking the 

EAI integration process to the next logical step by 'wrapping' and 

publishing traditional EAI method-level components as Web services 

via XML/SOAP and UDDI. As an example, IBM's WebSphere not only 

provides all the method-level and transactional integration of a distributed 

object application server (via EJB), but will also be able to 'wrap' the 

Java Beans in a SOAP-compliant XML interface and publish the services 

using UDDI to facilitate B2B communication. 

Traditional ERP, SCM and CRM vendors are now developing software 

solutions across the entire spectrum of the enterprise. The traditional 

'silo' vendors, those who concentrate on one type of solution, will 

either expand their offerings, merge with other vendors, or just disappear 

from the enterprise software business altogether. The new breeds of 

enterprise solutions are 'Internet-ready' with out-of-the-box Web/browser 

and mobile capabilities. In addition, the software will support B2B 

protocols providing seamless integration and allowing rapid deployment 

into B2B marketplaces.


The bottom line is that the marketplace is converging and merging at 

a rapid pace as software vendors look to provide a complete e-business 

solution. Literally, there are thousands of niche e-business, B2B, EAI, 

or enterprise software firms, each one providing a value-added service. 

Some of these firms will emerge as winners and survive in their own 

right. Others will be gobbled up by the 'big-boys' such as Microsoft 

and IBM, as these companies continue to flex their muscles by leveraging 

their current market penetration and domination. The remainder will 

probably atrophy and disappear. 

SCIQUEST GOES THROUGH EAI BEFORE 

IMPLEMENTING B2Bi 

SciQuest, a scientific products e-marketplace, maintains more than 

1.2 million products from more than 700 suppliers in its virtual 

catalog. When a customer places an order, SciQuest has to pass that 

information along to anywhere from two to thousands of different 

suppliers. SciQuest also has to link electronically to other partners, 

such as shippers FedEx and UPS. To have a truly automated order 

management process, they have to support a diverse range of systems 

of their suppliers, who have infrastructure as basic as e-mail and a 

Web browser to fairly sophisticated ERP and high-end EDI systems. 

SciQuest had to get its internal act together before its systems 

could effectively communicate with the outside world. As a part of 

EAI, the company had to link its Siebel CRM system and Solomon 

financial software to the DB2 database where up-to-date information 

about all suppliers' products is stored. That back-office infrastructure 

was then to be linked to the IBM Net.commerce Web catalog that 

lets its customers shop and buy from SciQuest online. 

Source: Condensed from EAI goes B2B, InternetWeek 

4.9. Divergence of EAI and B2Bi 

As B2B protocols and specifications mature, a schism will eventually 

develop between the roles of EAI and B2Bi. EAI models are typically


centralized within an organization, which tends to be a more efficient 

framework for integration. Conversely, B2Bi models have to support 

joint development activities and technology level agreements among 

independent organizations, a much more challenging task. 

In many B2B marketplaces today, companies are relying on proprietary 

EAI middleware to facilitate B2B communication. Many of these 

middleware solutions are mature, stable and battle-tested, providing an 

adequate framework for transacting over the Internet. This stability 

usually comes at the expense of accessibility, openness and scalability. 

Currently, B2Bi implementation is subjected to frequent changes as 

the industry standards change or the business processes of trading 

partners change. The eventual acceptance of evolving B2B protocols 

and standards such as SOAP/XML, UDDI, XMLT will promise to 

provide companies with a common, standardized framework for 

conducting B2B transactions, eliminating the need for proprietary 

software or constant rework. Once these standards become widely 

accepted in the marketplace, EAI will be relegated to middleware 

solutions such as messaging and distributed objects while B2Bi will be 

reduced to protocol-based communication, much like TCP/IP or HTTP 

is today. 

The other major area of divergence is security. With EAI, companies 

do not have to worry about encryption, firewall implementations, crossorganization 

distributed applications, or partner management, all of 

which pose difficult challenges in B2Bi. In addition, B2Bi implementation 

is inherently more complex from a global perspective, as it has to deal 

with different international laws regarding the use and export of 

cryptographic technology. 


Integration of enterprise applications is a key element of B2Bi strategy. 

EAI can truly make a company's B2Bi implementation a success or a 

failure. By integrating and streamlining business processes and the 

applications supporting them, EAI empowers enterprises to achieve 

higher operational efficiency, increased revenues and better customer 

service.


EAI is not just simple connectivity to databases and transaction 

managers, but the overall integration of legacy, ERP, CRM and SCM 

systems. 

EAI is indeed a very challenging goal as it aims to integrate multiple 

systems, platforms, business processes, people and data. An EAI strategy 

should be driven by business goals, leverage current infrastructure 

within an enterprise and use the right set of integration solutions, 

architecture and methodology.

Chapter 5 

Business Process Management 

(BPM) 


Business process management (BPM) enables enterprises to automate 

and integrate the disparate internal and external corporate business 

processes. It does so by supporting dynamic process topologies that 

allow the boundary between processes and participants to be determined 

either statically or dynamically on a real-time basis. 

In this chapter, we will present the fundamentals of BPM, especially 

as they relate to B2BL You will learn about business processes, process 

modeling, workflows and features of BPM systems — along with a 

discussion of leading commercially available BPM systems, business 

process markup language and standard business processes. 

125


5.1. Existence of 'Organization Silos' 

In today's typical small, medium or large sized company, only certain 

parts of the business processes that form the backbone of any company's 

business are automated. With little integration among different departments 

and systems supporting various business process activities, several 

isolated islands of information, known as organization silos, exist within 

a company. 

Much human intervention is required to complete these processes, 

causing increased response time and slower cycle time. Furthermore, 

several of the currently automated business processes are fragmented in 

nature, with applications and data underlying them owned by different 

organizational units. 

The primary goal of dynamic real-time B2Bi cannot be achieved if 

the underlying business processes are not automated and integrated to 

work at Internet speed with complete accuracy, flexibility and adaptability. 

A successful implementation of B2Bi requires a business process management 

(BPM) strategy that leads to sound end-to-end, cross-application 

and cross-organization business process integration. 

BPM enables collaboration among trading partners in a secured, 

scalable and reliable manner. It does so by supporting dynamic process 

topologies that allow the boundary between processes and participants 

to be determined either statically or dynamically on a real-time basis. 

5.2. Fundamentals of BPM 

This section describes the fundamentals of business process management, 

as they relate to B2Bi. 

5.2.1. Business processes 

A business process is a logical collection of tasks or activities involving 

internal and external systems and human decision-makers which needs 

to be achieved as part of an overall outcome for both an organization 

and, more importantly, for its customers. A business process can also be 

defined as one of the various processes needed within an organization 

to deliver service to its customers.

Business Process Management (BPM) 127 

There are start and exit rules associated with business processes that 

determine the control and data flow among the individual tasks. Each 

task is assigned to a user, an application, or any other system, based on 

the rules and consists of one or more transactions (see Figure 5.1). Each 

transaction is characterized by exchange of messages among the 

applications (both internal and external) involved. The messages consist 

of business documents, such as a purchase order and a request for quote 

along with the sender and receiver information, transport protocol and 

transaction control mechanisms associated with them. 


T»*k 1 

Talk 2 

Tj»«k3 

4- 

Closed Ous m 

Process 

Company A 

Figure 5.1. — A typical business process 

r~K 

i ill • i 

Figure 5.2. 

Closed business process 

.1..' 

Closed Business 

Process 

Company B 

l


Fundamentally, there are two types of business processes: internal 

(private or closed) (see Figure 5.2) and external (public or open) (see 

Figure 5.3). Internal processes control the information flow by coordinating 

interactions with business application systems within an 

organization, while external processes control interactions among 

independent trading partners. 

Business process lifecycle 

Generally, business processes of an organization have a continuous life 

cycle, going through phases and changes similar to the organization itself 

over time. The life cycle of a business process depends on its scope, 

which may be from process improvement to a new process design. 

Company A Company B Figure 5.3. — Open business process 

Goal 

Definition 

Business 

Process 

Ufecycle 

Figure 5.4. — Business process life cycle


A business process life cycle typically starts with a goal definition 

relating to the process and its integration potential (see Figure 5.4). The 

goal definition involves the scope, and in the longer term, the final 

objective of the process. The goal leads to a process modeling exercise 

using a graphical modeling tool to map the process. This leads to the 

stage of process execution. In process execution, the process map is 

tried with source and target systems to see the interactions and workflow 

of the process. The working of the process leads to the monitoring and 

control of the process in action which ultimately leads to the goals 

being redefined and/or the process being fine-tuned or modified to suit 

the requirements. 

Characteristics of a good business process 

In very simple terms, a good business process achieves the desired 

goals in an efficient and effective manner with as little latency as 

possible. In terms of B2Bi, the possible goals leading to better business 

performance and practice include: 

• Increased customer focus; 

• Improved planning; 

• Increased process improvement; 

• Better supplier relationships; 

• Increased people improvement; 

• Better information use; and 

• Better leadership. 

One of the key characteristics of a good business process is continuous 

improvement in the final objective of seamless B2B integration and zero 

latency to promote efficient practices. All the economic and performance 

indicators point to the benefits of going down the path of continuous 

improvement. Continuous improvement implies changing the performance 

of an organization to achieve, sustain and eventually reach the best 

practices in business processes as they relate to B2Bi. Here, best practice 

is the term used for management and operational practices that are more 

effective and efficient when compared to equivalent practices in other 

organizations.


A good business process is designed around three types of activities 

required for continuous improvement: 

1. Advanced concepts — Big-step improvements encompassing strategic 

initiatives, major projects and key business process innovations. 

2. Incremental improvement — Small-step improvements undertaken 

continuously by cross-functional or natural work teams as part of 

their normal day-to-day activities and job functions. 

3. Quality assurance — Establishes a sustainable base and standardizes 

process improvement, by rewriting procedures and conducting training 

in the new way of operation, so that any improvements that are 

made to the system are not lost over time but remain as standard 

operating practice. 

5.2.2. Participants 

The participants in a business process include applications, humans, 

trading partners, other processes and systems, which can be either static 

(these are known during the modeling of a business process) or dynamic 

(these are determined at the run-time of a business process). Emarketplaces 

offer a perfect example in which business processes have 

to deal with dynamic partners, as the buying or selling party is usually 

not known beforehand. The participants are the resources for a process. 

5.2.3. Activities 

Activities are units of work that are performed within a process. Active 

or passive resources are required to perform these activities. The same 

activity may be enacted in different processes and on different objects. 

Thus, activities should be designed in a reusable fashion. 

5.2.4. Business transactions 

A business transaction consists of exchange of messages resulting in a 

consistent change in the state of the business. Business processes can be 

composed of one or several business transactions. B2B transactions involve 

multiple enterprises and resources (such as databases, transactional


< S everal Reads> < Up dates Recorded* < Updates Appl i ed> 

\+- ±U wl4—— ——J > 

Tx Tx E nd Tx Tx 

Begin Abort Outside Transaction Begin Commit 

Figure 5.5. — A short-lasting B2B transaction 

 

U t.1 » 

Tx Begin In Transaction Tx Commit 

Figure 5.6. — A long-lasting B2B transaction 

objects and queues for persistent messages) that are managed and 

operated independently by each enterprise. Successful outcome of a 

transaction is dependent on the coordination of workflows, which drive 

business transactions, across multiple organizations. 

B2B transactions can be completed within a few seconds (see 

Figure 5.5) or can last over days (see Figure 5.6). Transactions that are 

long-lasting pose a unique challenge to the design and run-time execution 

of B2B applications. Consider an example where the buyer has placed 

an order with a supplier for shipment of some goods. This transaction 

will not be completed until the buyer actually receives the final delivery 

of the goods. 

A coordinated, flat transaction model requires maintaining full 

atomicity, consistency, isolation, durability and integrity of a transaction. 

It requires a two-phase-commit protocol in order to enable distributed 

transaction coordination and provides an all-or-nothing guarantee by 

assuring that all participants of the transaction agree to either complete 

the transaction or abort it. There is usually only a single layer of control 

required by the flat transaction model. 

But this approach does not always fit long-lasting B2B transactions. 

In such cases it is not practical to achieve isolation, as it requires 

enterprises to lock their databases while waiting for others to finish 

their part of the transaction. The extended transaction model, also


known as open nested transaction model, fits well in such scenarios as 

it allows the main transaction to be broken into independent and logical 

sub-transactions. The outcome of the sub-transactions is tied to the 

main transaction. If the main 'transaction aborts' all sub-transactions 

must abort. This model does not impose the isolation requirement, but 

maintains the all-or-nothing nature of transactions by using the processlevel 

forward and backward recovery approach. 

5.2.5. What is BPM? 

Although there are several interpretations and definitions of BPM, 

we will try to understand BPM as it relates to B2Bi. Business process 

management involves management of several components, including time, 

cost, quality, scope, human resources, communications, procurement, risk 

and integration. BPM is designed to streamline the internal and external 

business processes of a company through a combination of several 

techniques, such as designing workflows, process rules and application 

components. BPM is a required element to direct data flow among the 

mass of packaged applications, legacy systems, services and partners. 

It aims to automate business processes from start to finish, thereby 

eliminating the need for unnecessary manual intervention and removing 

all points of friction within the company and with its trading partners. It 

also enables the formulation of consistent business policies across the 

organization, which leads to consistent execution of business processes 

across all channels and applications. 

BPM's focus on explicit process management allows processes to be 

executed, monitored, controlled and modified with greater ease than in 

the past. Through BPM, companies can track and monitor the actual 

state of a business process at any time. 

It is worth mentioning that BPM is not intended to remove manpower 

altogether from supporting and running businesses. The goal of BPM 

is to let the personnel focus on what they are good at — thinking, 

rationalizing and making decisions by getting involved in exception 

management and process optimization. In fact, providing adequate support 

for human interaction is a vital feature of any BPM system. 

BPM, EAI and B2Bi go hand-in-hand (see Figure 5.7) as the elements 

or resources included in a workflow definition should be interoperable


Base of Integration 

Platform 

Figure 5.7. — BPM, B2Bi and EAI enable collaborative commerce 

Start L* Task A I 

Task B w»& Decision^ 

I 

m£>m>m>ai!stiBmmii& "fas k C I 

J 

W 

[ End J Figure 5.8. — An example of a workflow 

and provide the workflow engine the capability to invoke, execute or 

launch them. 

BPM gets very complicated for B2B applications, as the business 

processes not only span across multiple applications but also across 

multiple companies. This distributed nature of processes requires stable 

applications supporting them at each link. 

5.2.6. Workflow 

Workflow is defined as the process of automation of business process. 

A workflow can be represented as an ordered flowchart that is composed 

of one or many activities (that represent a logical unit of work) (see 

Figure 5.8). It is a way for organizing, formatting and representing a


business process so that it can be used by a BPM system. It defines the 

why (the goal of a business process), what (the activities/tasks that it 

involves, along with their input and output), who (who performs the 

activities and where the results go), where (the location — application, 

system, user — of the activities) and when (the order and timing of the 

activities) parameters of a business process. 

The BPM system included in a complete B2B integration suite 

provides a workflow manager or a workflow engine that works with the 

message broker to automate business processes. 

5.2.7. Roadmap to BPM 

Now that the basics of BPM have been discussed, it is time to understand 

how to achieve BPM within an organization. There are several logical 

steps that have to be followed sequentially. They are: 

Design and model 

Initially, the enterprise implementing BPM has to work towards mapping 

existing business processes in the form of workflows, flowcharts or a 

combination with any other approach. This groundwork helps the 

company to identify the areas of wasted effort in traditional processes 

and hence represents opportunities for improvement in the process. 

As far as designing a new process goes, according to ebXML.org, 

there are four distinct stages involved (see Figure 9.10) as follows: 

1. Gather Requirements — The first step in designing a new business 

process is gathering requirements based on the statement of intent. 

Developing the statement of intent helps the business users in getting 

clarity about the scope and purpose of the business process. After 

the statement of intent has been prepared, users should start the 

process of gathering the requirements from all company departments 

involved in the concerned business process. 

2. Analyze Business Process and Business Information — Once the 

requirements are identified, the business analysts analyze all aspects 

of the business process so that it takes in the right input and 

produces the right output. Several entities including trading partners,

Statement of 

Intent 

Gather 

Requirements 

Requirements 

Documents 

Source: ebXML.org 

Analyze 

Business 

Process & 

Business 

information 



Definition, Document 

Definition 

Develop 

Schemas 

I 

Document Schema 

XML Samples 


Definition 

Implement 

rik. Service/ 

Application 

Figure 5.9. — Steps involved in designing a new business process 

industry standards organizations and other existing models can act as 

the source for the analysis process. 

Develop Schemas — The next step in designing a new business 

process is to develop schema that truly represents it, which involves 

creation of the document and information component schemas (XML 

schema/DTD or EDI message and data element definitions) and 

sample documents. 

Implement Service/Application — The last stage in designing a new 

business process is the final implementation of the business service 

interfaces and services/applications (such as back-end systems) in 

accordance to the business process definitions and the document 

schemas. 

Business process design stages 

For all the new business processes or existing business processes to be 

automated, the business users have to create visual models using a 

process modeling tool.


Company X creates a Sales_ 

Forecast_Message. 

Company Y processes Sales_ 

Forecast_Message 

Company Y evaluates the 

sales forcast figure. 

Company Y sends Jales_ 

Forecast_Acknowledgment_ 

Message 

Company X processes Sales_ 

Forecast_Acknowledgment_ 

Message 

Processes ends when Company X 

approves the sales forecast. 

\c\ 

Sales_Forecast_ 

Message 

Company Y sends Sales 

_Forecast_ 

Revision_Message 

N 

Sales_Forecast_ 

Acknowledgment^ 

Message 

If necessary, 

Company X 

sends a revised sales 

forecast figure 

Revised. 

Sales_ - 

Forecast 

Revised_ 

Sales_ 

Forecast 

Figure 5.10. — Modeling of collaborative sales forecast business process 

Here is an example of business process modeling: in its simplest 

design, a collaborative sales forecast business process enables two 

trading partners (Company X and Company Y) to forecast, review and 

adjust sales forecasts in an iterative manner until they both arrive at an 

agreement (see Figure 5.10). 

The company that has a higher forecasting capability, let's say 

Company X, initiates the business process. As the first step of the 

business process, Company X sends a message (Sales_Forecast_Message) 

to Company Y with data pertaining to sales forecast. Company Y 

receives the message and evaluates the data. The process of evaluating 

and determining if the sales forecast is correct does not fall within the 

perimeters of BPM. 

Based on whether any change in forecast is needed or not, Company 

Y sends Company X one of the following:


• An acknowledgement message (Sales_Forecast_Acknowledgment__ 

Message) if no forecast revision is needed; or 

• A forecast revision message (Sales_Forecast_Revision_Message) if 

the forecast does require a change. 

On receiving a response message, Company X can do one of the 

following: 

• End the process — if the response is an acknowledgement indicating 

that Company T accepts the sales forecast data. 

• Process the data and review the changes — if the response is forecast 

revision. If Company X accepts the change, the process ends. 

• Send a message (Sales_Forecast_Revision_Message) with revised sales 

forecasts — if Company X does not agree with the revised figure 

from Company Y. 

The process continues to loop until both partners have reached an 

agreement. Company X will end the process, as it is the initiator of this 

business process. 

Automate 

The objective behind automating a business process is to bring its 

latency to zero. Automation can be achieved through wastage reduction, 

streamlining the process to reduce duplication, and by having a good 

workflow. By automating the process, an organization achieves the 

desired productivity and real-time information for internal and external 

users. Automation does not mean the removal of human interface, but 

more efficient use of human interface. 

Executing processes 

The next step is to use the process models to execute the processes, 

directing the flow of information as needed to and from a company's 

internal IT systems and over the Internet to the IT systems of its 

partners, suppliers and customers. 

There are three approaches to executing processes: logical, physical 

read-only and physical write-only. These approaches have different


levels of risk involved in terms of things going wrong and different 

levels of impact on maintaining the system's integrity. 

Using a logical approach process execution engine executes business 

process models without the need to change states at either the source 

or the target applications. This approach is recommended when no 

risk of making any real changes to the organization systems is to be 

taken. However, it does not inform about the problems ahead in real 

implementation. 

A physical read-only approach allows the process execution engine 

to only read information from the source systems. This approach allows 

the analyst to read and move information, but avoids updating the target 

systems. The read-only approach is second in terms of risk and has low 

risk in terms of the system's integrity. The model allows lesser power in 

terms of applicability, but has better value than the logical approach. 

The reading and processing of information has limited use if the target 

systems remain unaffected. The approach could be a compromise if the 

trading partners have differing attitudes to risk-taking. 

A physical read-write approach provides process execution engine 

with complete access to try the model on the source and target systems, 

which is the aim of full integration. As one would expect, this approach 

comes with the highest risk of the three approaches. Detachment of test 

systems from the organization's key systems could reduce the risk. The 

reason for minimizing the risk is the fact that any bug in the process 

model would result in an unstable state in the target or the source 

system which might not be acceptable to most organizations. 

Analyze 

For any process to work, it has to be supported with statistical analysis 

and data from organizations and monitored for improvement. Regular 

monitoring, recording and reporting of business operations will provide 

a wealth of information for analysis, interpretation and improvement of 


The analysis part of processes is extremely important, as that is 

where an organization learns from its inefficiencies and mistakes. There 

is a feedback involved in this phase from all interested parties, in order 

to design a meaningful process.

Adapt 


Adaptation of the designed processes within the organization and the 

customization of the standard package of BPM software forms part of 

the adapting phase of BPM. Training and follow-up of the personnel 

involved is an important component for the adaptation and acceptance 

of processes. 

5.3. BPM Systems 

Currently, there is a big convergence going on in the integration software 

industry, where the EAI and B2Bi vendors are embracing BPM tools by 

including them in their integration solution suites. 

There are certain mandatory components of a BPM system, as follows: 

Process modeling tool 

This is a graphical modeling tool that enables rapid visual design 

of business processes while hiding the implementation from the 

users. The tool should provide the functionalities of modifying user 

interfaces, business rules and process rules that drive the working of a 

business process. 

Process modeling involves drawing a workflow diagram that links 

resources, logic and movement of information between systems. Subprocesses 

are used when the main process becomes too complex and 

needs to be broken down to keep it simple. 

The process-modeling tool provides an environment to bind the 

components (process models; real entities such as companies, organizations, 

or people; source and target systems of the trading partners) of a 

business process together to create the final model for the process. 

Advanced modeling tools also include XML-based rules repository, 

so that the rules can be shared across multiple applications in a single 

uniform format. 

Process execution engine 

This component is responsible for providing an environment for executing 

the process flow — i.e., sequencing and invoking the required element


as defined in the process design. The process execution engine manages 

a set of installed processes and coordinates their execution, thereby 

integrating applications and operations irrespective of the underlying 

platform. It interacts with the B2B integration server to exchange 

information with applications, control execution of individual steps and 

state transitions for running processes. All its actions are persistently 

logged to the database so that the users can analyze the data through a 

reporting tool. 

Since B2B applications may involve heavy loads, the execution 

engine should be able to manage a large pool of concurrently running 

processes. In addition, it should provide checkpoint/restart capabilities 

that enable recovery from system failures. 

Process administration tool 

This tool provides administration functionalities to the users to monitor 

the state of processes and act in the event of exceptions, such as 

changing the execution sequence. 

Process reporting tool 

The process reporting tool may be included in the administration tool or 

may be provided as an independent component of BPM system. This 

tool is responsible for generating and presenting different reports such 

as statistics and performance which help companies to optimize processes 

by removing any bottlenecks. 

A BPM system should functionally provide the following: 

Support for open standards 

Since B2Bi requires integration of processes across corporate boundaries 

using exchange of XML-based documents or messages, the vocabulary 

used for communication between different systems should be based on 

open standards. The BPM system should support all the leading XML 

standards which define the vocabulary and/or the business processes, 

for instance, RosettaNet for electronic component industry and OBI for 

purchase management.


Additionally, it should include basic business process designs and 

their associated XML data definitions for all the major vertical industries. 

For instance, a BPM system being used by a B2B exchange must 

include pre-designed processes and sub-processes for Partner and 

Enterprise Management (Account Information Exchange, Collaborative 

Account Information Exchange), Procurement (Price and Availability 

Exchange, Collaborative Price and Availability Exchange, Price Change 

Announcement, Request for Quote, New Product Information Exchange, 

Request Product Information, Order Management), Order Fulfillment 

(Order Fulfillment, Invoicing, Shipping Invoice, Inventory Management, 

Inventory) and Logistics (Returns Management, Shipping Notice, 

Shipping Request, Shipping Status). 

Easy integration with applications 

A typical business process may be supported by multiple diverse 

applications such as ERP, CRM and legacy systems. It is virtually 

impossible for a BPM system to manage a workflow and execute the 

different tasks associated with it, which may require using APIs of 

other systems or exchanging messages with them, unless it provides 

easy integration facilities. A BPM system should also provide easy 

connectivity by publishing an API to other applications. 

Support for different middleware technologies 

BPM systems should provide support for all the different middleware 

technologies such as messaging (JMS), distributed computing (EJB, 

COM+), RPCs (RMI) as each task/sub-task of a business process may 

require the use of one or a combination of these technologies. 

With such wide technological support, a BPM system can fully 

leverage a company's existing infrastructure, thereby significantly 

increasing the ROI on business process integration. 

Several leading EAI tool companies provide BPM systems as an 

independent application or package it together with their application 

integration servers. 

A few leading commercial BPM systems include:



BEA WebLogic integration is a platform that includes application server, 

application integration, business process management and B2B integration 

functionalities. In this section we will focus on the BPM aspect of the 

software suite. 

BEA WebLogic integration takes a process-centric approach to B2B 

integration and allows channel-masters and their business partners 

to model, execute and easily manage business processes among 

organizations. With intuitive design tools (see Figure 5.12) and an 

award-winning process engine, BEA WebLogic integration empowers 

the business analyst to design collaborative business processes and 

integrate them with internal processes and systems. At run-time, the 

process engine manages the execution of defined business processes 

(see Figure 5.11). Monitoring capabilities enable companies to identify 

bottlenecks and optimize processes on-the-fly, without interrupting 

ongoing processes. 

In this BPM system, collaboration-specific processes exist separately 

to protect proprietary information during interactions between individual 

companies. Shared processes, defined and managed collaboratively, are 

deployed as local processes and execute only at each trading partner 

site to ensure that private information remains secure. 

HOW TO 

Invoke 

Events 

BPM Template | 

Definition 

(Studio) 

Process Engine 

wk m 

Template 

Store 

Instance 

Store 

HOW To 

Integrate 

XMLEvent ,.--- 

'uj"'-"Sr Application 

XML 

RMI --"" EJB ""-v 

...Componentjjj*' 

Sys Ekec 

BPM Monitor 

(Studio) 

Figure 5.11. — BEA-BPM execution engine 

Applicati tion J|

S Webtogic Process Integrator Studio 

File View Toots Window Help 

Organization 

Templates 

Order Fulfilment 

Order Processing 

05/01/01 12:00AM 

: Order Processing Tripper 

' L ' ; 07/12/00 12:00AM 

t : Starts 

: ••• Events 

•+' r' Tasks 

• Decisions 

• Joins 

• Exception Handlers 

+ Variables 

Calendars 

Users 

Roles 

Routing 

Statistics Report 


::.WMKfuw Deslon Ortte'f.Processiila qs/os/oi ISP-PM.: 

m Workflow Design Order Fulfilment 06/09/01 2:00 PM 

Figure 5.12. — BEA process modeling tool 

5.3.2. Vitria BusinessWare 

BusinessWare's BPM component is capable of modeling and automating 

simple to complex business processes within and between organizations. 

Typical internal business processes could include order fulfilment and 

inventory management-type processes, while business-to-business processes 

can include provision of services, supply chain management and 

multistep purchasing transactions. 

Automator in the BusinessWare software is the primary component 

for process management and provides the process modeling environment 

and the process execution engine for handling high volumes of business 

transactions (see Figure 5.13). It also enables a company to create 

visual models of business processes and executes those business process 

models by directing the flow of information among the underlying 

internal and external IT systems and workers that perform the steps 

defined in each process. Automator can then adjust or change the


Business 

Process 

Man Jig* mn nt Process Mod eli ng 

Automato: 

Workflow 

Process Automatio r 

Figure 5.13. — Vitria automator connects EAI, B2B processes 

ongoing business processes as per user-defined rules based on the 

feedback received from the real world live process execution. 

BusinessWare allows a separation of business process definition 

from back-end integration and system issues, which is a key feature. 

The business processes are best understood by businesses and the 

people running them, hence the processes should be left to them to 

design and manage. 

5.3.3. Extricity B2B Alliance Manager 

Extricity B2B Alliance Manager provides an integrated development 

environment for modeling graphically inter-company business processes 

and defining business objects (the data that is exchanged). The resulting 

workflows define the sequence of events, the partners and the logic. The 

development environment supports event triggers, threaded conversations, 

timing control, conditional logic, alternative and parallel routing of 

documents and more. 

Extricity offers B2B Process Paks, which are packaged process 

solutions that enable organizations in specific industries to fast track the 

development of business with their trading partners. Process Paks make 

implementation faster and easier by delivering unique best-practice B2B 

processes that work the way organizations want them to work. One can 

modify and customize the Process Paks, working in the intuitive dragand-drop 

environment provided by the software solution. 

Presently, Extricity provides Process Paks for the following industries: 

Consumer Packaged Goods, E-retailers, Logistics Services, Net Markets, 

RosettaNet and Semiconductors.


TSMC: BEFORE AND AFTER — 

A COMPELLING DIFFERENCE 

Taiwan Semiconductor Manufacturing Company (TSMC) is the world's 

largest contract manufacturer of integrated circuits, offering its 

customers turnkey services from design and fabrication through test 

and assembly. TSMC has revenues in excess of $1.5 billion and has 

400 customers around the world. TSMC offers custom-made integrated 

circuits for its customers. The business environment in the integrated 

circuit industry requires short product life-cycles, growing customer 

demand and an increasing need to differentiate itself from its 

competitors by offering value-added services. 

In the past, TSMC found that its methods of communicating with 

customers and suppliers, which included its Website, fax, e-mail, 

FTP, EDI, etc. were slow, time-consuming and limited in the volume 

of information and the timelines with which they could transmit the 

information. These inefficient communication methods were creating 

delays along the supply chain. 

In 1997, TSMC choose Extricity B2B for improving the way it 

interacted with its customers and, also to incorporate the customers 

in its internal processes at the manufacturing stage. The automated 

and shared business processes were in the area of collaborative 

engineering, forecast sharing, order management, WIP (work-inprogress) 

updates, shipment notifications, linking back to its own 

suppliers. With these areas of shared processes, TSMC was able to 

achieve significant improvements in customer satisfaction and supplychain 

efficiencies. Customers now have the information that they 

require, whenever they require, in the format required, in and through 

their enterprise systems. Apart from reduction in TSMC's customer 

lead-times by up to 25% and elimination of manual processes, there 

has also been a reduction in WIP inventory carrying costs and improved 

capacity planning. Based on total project costs and quantifiable 

benefits, TSMC had a return of 14 times on its investment in the first 

three years. 

With Extricity B2B, TSMC has implemented a business-to-business 

integration solution to connect its suppliers, contract manufacturers 



Assembly & Test 

Supplier 

TSMC 

[Sriririai| [ fOM~ ] [Engineeririgj 

Collaborative Business Processes 


Figure 5.14. — TSMC's B2B integration implementation 




and customers (see Figure 5.14). This has created an integrated virtual 

supply-chain base to allow interactions and satisfy the individual 

customer's needs. 

The integrated collaborative processes that are offered by TSMC 

to its customers are: 

• Engineering Design — for prototype specifications of customers to 

be tested and iteration of the process until a satisfactory design is 

finalized. 

• Forecast Sharing — customers automatically provide TSMC with 

demand forecasts on a regular basis. 

• Order Management — the system delivers purchase orders directly 

from the enterprise systems of TSMC's customers into TSMC's 

total order management system. 

• WIP Updates — four types of WIP data are generated daily from 

TSMC's manufacturing systems, formatted to meet each customer's 

requirements and sent via the Internet. This provides customers 




with visibility in the manufacturing status of their products, allowing 

more informed decisions. 

• Ship Notice — TSMC notifies customers about finished products, 

which provides them with advance information and progress updates. 

With the implementation of Extricity B2B system, TSMC is 

predicting a ROI of 1400% over a three-year period, which equates 

to a five-month payback. 

Source: Condensed from Extricity customer case study; The TSMC story, Extricity.com 

5.4. Universal Language for BPM 

There are several practical challenges in the real world implementation 

of BPM. For instance, there are no de facto standards available for 

business process modeling. Multiple groups demand different levels of 

abstraction in the design and execution of processes, and different BPM 

systems communicate by exchanging messages that have no standard 

formats, making B2B-based business process integration challenging. 

According to the Gartner Group, through 2005 no standard will fully 

eliminate the requirement that enterprises must support multiple, 

incompatible process-management-aware applications. 

There is a need for a universal language, which can be used to design, 

deploy, maintain and execute business processes, such as order management, 

demand and forecast planning and new product development. 

This language should represent all the internal and external activities 

that support any company's business — for instance, synchronous and 

asynchronous communication with all internal and external applications, 

information dissemination, short and long-lived transactions. It should 

be based on open architecture so that the process models among different 

BPM systems can be exchanged and should enable the creation of 

a common business process repository. Further, it should allow a 

mechanism for expressing rules for business level validation of messages, 

to link processes to events occurring in the environment and to express 

data extraction. Finally, it should provide full support for the existing


B2B collaboration protocols such as RosettaNet, BizTalk and ebXML, 

as well as technology integration standards, including J2EE and SOAR 

Business Process Management Initiative (BPMI) is leading an effort 

to develop a universal language for modeling, deployment and execution 

of business processes. There are two major direct competitors of BPMI: 

XLANG process specification language, a Microsoft initiative, and Web 

Services Flow Language (WSFL), an IBM initiative. 

Note: Web Services Flow Language (WSFL) is discussed in the chapter 

on Web services. 

5.4.1. Business Process Management Initiative (BPMI) 

The Business Process Management Initiative (BPMI.org) is led by several 

leading companies including: Hewlett-Packard Co., Art Technology 

Group, Sun Microsystems Inc., Tibco Software Inc., Computer Science 

Corporation, Cyclone Commerce, DataChannel, Entricom, Ontology.org, 

SI Corporation, Versata, VerticalNet and Verve. BPMI.org is developing 

the Business Process Modeling Language (BPML) and Business Process 

Query Language (BPQL). 

Business Process Modeling Language (BPML) 

BPML is an XML-based, open standard, meta language for the design, 

definition, deployment and management of business processes that span 

multiple applications, corporate departments and business partners. BPML 

is actually an XML schema that provides a standard way to model 

mission-critical business processes. It aims to allow tighter integration 

and collaboration in business processes than the current application 

interface model. BPML is to BPM as XML is to e-commerce. 

BPML, like any other business process standard such as ebXML, 

RosettaNet, is based on a message-based model. In message-based 

models, the participants involved in a business process interact through 

the exchange of messages. The business process determines the manner 

of the message flows and the information contained within them. The 

semantic and syntactic structure of messages is defined using BPML 

XML schema.


BPML uses XPath as the basis for its expression language. XPath 

provides a declarative expression language with rich semantics for 

expressing condition logic, calculations and selection predicates. 

Business Process Query Language (BPQL) 

The Business Process Query Language (BPQL) intends to provide 

a standard interface for business process deployment (in a process 

repository) and execution (in a process server). BPMI.org is still 

developing this language. 

The interface for process repository is based on the Distributed 

Authoring and Versioning Protocol (WebDAV). It would enable users to 

manage the deployment of process models contained and managed by 

the repository. These process models could be exposed by the enterprises 

as Web services for process registration, advertising and discovery 

purposes. 

The BQML interface to a process server gives the users the 

capabilities to query and control the state of execution of process 

instances managed by the server. It is based on the Simple Object 

Access Protocol (SOAP). 

5.4.2. XLANG 

XLANG, an initiative of Microsoft, is an XML-based language that 

describes the logical sequencing of business processes and their 

implementation by using various application services. It is expected to 

serve as the basis for automated protocol engines that can track the 

state of process instances and help enforce protocol correctness in 

message flows. 

5.5. Standard Business Processes 

A key requirement of B2Bi is the ability to describe business processes 

in a standard form that can be consumed by tools for process implementation 

and monitoring. Currently, there are several organizations 

that are trying to standardize business process standards for their vertical


industry. These business processes are defined according to a wellknown 

model, described in agreed-upon formats, which is made publicly 

available and which can be contractual in nature. 

As discussed, in B2B applications business processes span corporate 

boundaries. Each company has its own applications and workflow 

implementation technology. In such a case, loose coupling based on 

predefined external protocols provides integration of business processes. 

These protocols are message oriented, specify the flow of messages 

representing activities among the trading partners in a business process 

and standardize the format and content of the messages, leaving the 

implementation part completely opaque. Each company can have its 

own implementation, which is completely changeable at any time as 

long as the generated messages are based on the protocol. 

For instance, RosettaNet, an independent consortium, is standardizing 

business process standards by publishing XML-based Partner Interface 

Processes (PIPs) for IT, electronic components and semiconductor 

industry. The PIPs define processes for a wide range of business 

activities in this specific industry, such as inventory, pricing, sales 

management, order handling, product configuration and shipping. 

Electronic Business XML (ebXML), which is jointly sponsored by 

the United Nations Center for Trade Facilitation and Electronic Business 

(UN/CEFACT) and the Organization for the Advancement of Structured 

Information Standards (OASIS), provides a standard method exchanging 

business messages, conducting trading of relationships, communicating 

data in common terms and defining and registering business processes. 

A detailed coverage of RosettaNet and ebXML can be found in the 

chapter on XML Standards. 


BPM enables enterprises to automate and integrate the disparate internal 

and external corporate business processes. It does so through the effective 

and efficient design, deployment, execution, management and analysis 

of business processes. BPM enhances flexibility, adaptability and servicelevel 

management, while making the business more visible, measurable 

and auditable.


BPM systems are increasingly becoming a core segment of the 

major integration platforms available commercially. They include a 

point-and-click visual modeling tool through which the business analysts 

and developers can design and build distributed business processes that 

can be deployed immediately and changed in real-time. At the core of 

BPM systems is an execution engine which routes messages or events 

from integrated applications, based on the rules and the state of the 

current business process, to different participants of the process, whether 

they are people or systems.

Chapter Q 

Extensible Markup Language 

(XML) 


Extensible Markup Language (XML) has now become the lingua franca 

of the B2B e-business revolution. Since it is both universal and flexible, 

XML has become one of the fundamental components of B2Bi, enabling 

systems to share data and add value as data is passed from point-topoint. 

In this chapter, you will come to understand the importance of 

XML, its components and its coexistence with the traditional mode of 

communication — electronic data interchange (EDI). We have also 

provided in-depth coverage of the features of XML/EDI servers. 

152

Extensible Markup Language (XML) 153 

6.1. The Need for a Universal Language 

In order to participate in B2B e-commerce, companies are moving 

towards customer self-servicing, enterprise application integration and 

dynamic partnering with external companies and exchanges. This changing 

nature of doing business has significantly increased the complexities of 

processing business data. The data in this business environment can be 

found in varied formats, such as messages from different trading partners, 

internal corporate documents, messages from retail customers, several 

interfaces to transaction-based systems, databases and Web pages. 

Capturing, managing and effectively using business data has become a 

wobbly task. 

Due to the lack of a universal data interchange format, companies 

are not able to fully exploit automation, both internally and externally, 

that would enable seamless communication between internal applications 

and external partner applications. As a result, most information 

technology departments spend upwards of 40% of their time in extracting, 

re-defining and updating data to serve specific needs, according to a 

recent survey from Forrester Research. 

It is impossible to even dream of B2Bi based on the Internet, 

without a universal language that is understood by every party involved 

in integration. Through the use of this language, companies will be 

able to transact business across organizational boundaries. Its use in 

exchanging business data among cross-organization applications is a 

key requirement for e-business success. 

Companies in the same vertical industry that usually relate to each 

other as competitors, will benefit tremendously by collaborating on a 

universal data exchange format for business documents, such as invoices 

and purchase orders. All the companies have to participate in this 

transition to universal data format language for it to be successful. So, 

apart from adoption by the Fortune 1000 companies, it also has to be 

embraced by an estimated 25,000,000 small and medium enterprises 

(SMEs) in the world. 

Let's briefly review Electronic Data Interchange (EDI), a traditional 

method — and still the dominant way companies exchange information 

electronically.


6.2. What is Electronic Data Interchange (EDI)? 

EDI involves electronic exchange of routine business transactions. These 

transactions include documents, such as purchase orders, invoices, 

inquiries, planning, acknowledgements, pricing, order status, scheduling, 

test results, shipping and receiving, payments and financial reporting. 

Through EDI, these highly secure documents are exchanged in a 

compressed, machine-readable form over private value-added networks 

(VANs). EDI permits hundreds of companies to communicate and process 

business transactions electronically. In fact, EDI-based transactions over 

proprietary private networks account for 'the bulk' of the goods and 

services that businesses exchange electronically. 

EDI enables long-term relationships among trading partners and it is 

designed to address only those particular kinds of B2B relationships. 

For example, EDI messages are exchanged back and forth in a preestablished 

relationship of buyer and supplier, to maintain inventory of 

products and manage the logistics of shipping. This way a retailer could 

immediately let a warehouse know of an order and the warehouse could 

immediately notify suppliers of a change in inventory. 

One word in the above paragraph is of prime importance to EDIbased 

relationships — 'pre-established'. The relationships are preestablished 

and static as opposed to dynamic relationships, which are 

open to interactions to all newcomers. 

6.2.1. How does it work? 

EDI works by providing a collection of standard message formats and 

an element dictionary that can be exchanged via any electronic messaging 

service. EDI is based on standards developed according to the guidelines 

of the American National Standards Institute (ANSI), the coordinator 

for national standards in the United States. The ANSI committee ensures 

that everyone using a process such as EDI follows the same rules and 

methods, making the program universally accessible. As a result of the 

standard, all businesses using EDI share a common interchange language, 

which minimizes the need for change in internal data processing systems. 

EDI traffic is mostly composed of companies transferring bulk files. 

EDI trading partners seldom connect to each other directly. Instead,

Buyer 

Purchasing 

Accounts 

Payable 

a 

t 

1 

0 

ft 

S 

u 

i 

t 

e 

Purchase Order 

VAN or Direct 

Connection 

Invoice 


Remittance Advice 

Supplier 

Ordering 

Billing 

Accounts 

Receivable 

Figure 6.1. EDI-based communication between trading partners 

they use the services of VAN whereby each trading partner connects to 

the VAN (see Figure 6.1). The service provider of VAN manages the 

connections to all trading partners. 

6.2.2. Limitations of traditional EDI 

The setup procedure for traditional EDI is expensive, complex and 

time consuming. The inherent nature of EDI communication requires 

the trading partners to synchronize their internal systems and business 

processes with those of their partners. The different applications 

used by the trading partners use different schemas and data exchange 

protocols. The format and data content of the files generated by these 

systems also vary widely. The transfer of files containing data between 

trading partners, from one computer system to another using EDI, 

is also a potentially complex process. The EDI-based file exchange 

mechanism will work correctly only if programs running at both ends 

(sender and receiver of file) are part of the same package written at the


same time. Thus, there is a complete dependence by everyone in a 

business relationship on the adoption of a specific implementation. This 

unwanted feature makes continued changes, improvements and 

enhancements, either at the individual enterprise or trading group level, 

very expensive. 

The software, hardware and network connectivity of an EDI network 

is expensive and specialized. Out of millions of companies that conduct 

business with each other, only 300,000 companies worldwide have 

adopted EDI, due to its complexity and expense. 

The dominant partner model that drives EDI is too limiting and 

centralized in the Internet world. EDI relationships are usually hub-andspoke 

type, where the big corporation is the hub and all other small 

companies doing business with it are the spokes. The big corporation 

tends to dictate business and technical standards in its interactions with 

the smaller companies. This type of business model is not suitable for 

B2B e-commerce, as the latter is based on the emergence of many new 

and often short-lived business relationships and many kinds of payment 

arrangements. 

To summarize: 

• EDI is primarily a one-to-one technology, while a typical B2Bi over 

the Internet requires many-to-many connectivity. 

• Adding trading partners under traditional EDI requires customized 

mapping of each new partner's document formats. 

• Most EDI traffic flows over VANs, which can be expensive. Typical 

VANs charge $1 to $20 for each message. 

• As usage of VAN is expensive, EDI messages are compressed using 

algorithms. This makes the messages only machine readable and 

extremely difficult to debug. Just a small mistake in message formation 

can lead to hours of programming effort in detecting the problem. 

• EDI requires the installation and maintenance of dedicated servers that 

cost upwards of $100,000. But, wait. That's not all. The operational 

costs associated with EDI are also significantly high, as companies 

can spend $250,000 per month just in preserving the connection to 

the EDI network and keeping the servers up and running. This is too 

steep a cost for small and medium size industries and thus they 

refrain from adopting EDI.


6.3. What's Wrong with the First Language 

of the Internet — HTML? 

In the early 1990s, Hyper Text Markup Language (HTML) was 

developed, enabling both machines and humans to read the same 

document. Although HTML has been very successful as a markup 

language for the Internet, there are certain inherent drawbacks and 

limitations in the language that make its use in B2B specific applications 

very limited. 

Let's discuss some of the major limitations from B2Bi perspective: 

It is solely a presentation technology 

One of the key requirements for B2Bi is to be able to transfer meaningful 

documents among the trading partners. However, HTML focuses solely 

on presentation of text, not on what the text signifies. It does not reveal 

anything about the context of the text to which HTML tags are applied. 

Consider an HTML tag example, Orange which has a specific 

presentation in the Web browser. HTML fails to reveal anything about 

the context — 'Orange' — that is presented in the document. 'Orange' 

in this document can potentially mean anything like a wireless company, 

a fruit or a last name. Thus, HTML tag names don't describe what 

content is. They only imply how content appears. 

It does not capture business rules and processes 

B2B applications, in almost all instances, interface with the back-end 

systems, often a database. Data flowing between these applications in 

HTML format loses all useful information that is available in the 

original format of the data. Additionally, HTML data is strictly static 

and read-only. The users or applications cannot sort, query or process 

this data. HTML documents fail to capture any business process or rule. 

It is fixed data set 

In B2B applications, flexibility in the data sets that contain the data is 

of prime importance. These data sets have to be created on the fly,


based on the nature of the application. It is not possible to extend the 

data set on which HTML is based to create new tags that are meaningful, 

useful and necessary for applications. Only the W3C (World Wide Web 

Consortium) can extend the data set for HTML. Thus, HTML only 

describes documents of a single type. 

Data is hard to process 

HTML data is hard to process. Browsers permit several syntactical and 

structural errors of HTML to pass, unchecked. It is not possible to 

extract any meaningful, structured information from an HTML document. 

Apart from this, HTML documents can only be divided into a head and 

a body. So, there can be no logical break up of information in the 

document. For example, it is not possible for a browser to request only 

a specific user information section from an HTML document that 

contains information about many users. The browser can request and 

present only the whole document. 

6.4. XML: The Universal Language of 

Data Interchange 

XML is the 'universal language of data interchange' as far as the 

exchange of data among diverse applications written in any language 

and running on heterogeneous platforms is concerned. The use of XML 

makes it fairly easy for applications to exchange, interpret and act on 

data. XML fully leverages Internet, as XML-based messages can be 

exchanged over the Internet using Hypertext Transfer Protocol (HTTP) 

or HTTPS (SSL — Secured Sockets Layer HTTP). 

XML provides an efficient means of separating the data and structure 

from documents representing business processes. Based on these virtues, 

XML promises to enable the development of B2B e-commerce applications 

that are purely data-driven. The potential impact is significant: XML 

compliant application servers, Web servers, internal legacy applications, 

ERP systems and external applications can all quickly make their information 

available in a simple and usable format. 

Since XML is both universal and flexible, it has become one of the 

most powerful components of B2Bi, enabling systems to share data and


add value as data is passed from point-to-point. The use of XML allows 

trading partners to concentrate on their own internal business processes 

and can even change at their own convenience. For example, Company 

A can use XML to communicate with Company B, regardless of what 

internal systems each company is using. To do this, Company A converts 

the data that it wishes to share with Company B into XML format. All 

the two companies have to do is agree on a set of tags (or use a 

standard set from their industry). 

6.4.1. The power to know 

Real-time availability and access to business data is the key to making 

the right business decisions at the speed of the Web and keeping 

companies one step ahead of their competition. In a B2B integrated 

environment, companies have to capture, integrate, explore, analyze and 

exchange information from across the entire enterprise and with all the 

trading partners. 

In order for the companies to get the power to know, the data has 

to be: 

Captured — The business information, data and context have to be 

captured as and when they are produced and generated by the source. 

Storing the context helps in the meaningful search of the data. 

Managed — Managing electronic data, which is choking the corporate 

databases and other storage systems, has become a very big challenge. 

It is estimated that up to 7% of the revenue can go into the creation and 

movement of documents. Companies should work on consolidating 

information in a centralized knowledge base. This would not only help 

in getting rid of redundant data, but would also provide a complete 

picture of your business processes. The consolidated data is easy to 

maintain, organize, publish and search. 

Published — The whole idea behind capturing and managing data is to 

publish it for the user community. This data can either be pushed or 

pulled from the corporate databases and should be presented in any 

easily understandable format. The data should be presented based on 

the entitlements and interests of the users.


Exchanged — In a connected business environment, companies should 

be able to exchange and share data with multiple companies dynamically. 

The data can be transferred using either dedicated connections or over 

the Internet. In order for companies to exchange data on a real-time 

basis, they have to establish a common taxonomy for defining the 

structure and context of information. 

XML is the universal language that helps companies achieve all of 

the above tasks. It enables organizations to capture, manage, publish 

and exchange information with their partners, suppliers and customers 

as efficiently as possible. 

The fundamentals of XML, its strengths and weakness and its 

benefits over EDI are explained below. 

6.4.2. What is XML? 

XML is a language developed by W3C for visual presentation of 

factual information that can facilitate the exchange of data between 

applications and/or humans. 

Although the origin of both HTML and XML is the same — Standard 

Generalized Markup Language (SGML), HTML is designed primarily 

for just the presentation of hypertext pages in browsers; XML, on the 

other hand, is designed to create new markup languages for new 

document types. HTML restricts the users to only a few set elements 

defined by W3C such as , and . XML enables 

the users to define new elements for processing information in their 

particular domain, context or field. Creation of document types, tag 

sets, building XML documents and the behavior of XML processor, 

which parses the XML document, are all determined and based on 

specifications of XML 1.0. The specification of XML can be obtained 

at http://www.w3c.org/xml. 

The concepts on which XML is built are pretty straightforward: 

the meaning of the data in an XML document is specified by the 

tags on data elements and the relationships between different data 

elements in the same document is provided via simple nesting and 

references. Thus XML not only specifies data elements, but also their 

semantics.


However, XML is simply a data definition language, not a technology. 

XML cannot by itself integrate different systems. 

6.4.3. XML: A derivative of SGML 

The parent of Extensible Markup Language (XML) is the Standard 

Generalized Markup Language (SGML), an international standard for 

the definition of device-independent, system-independent methods of 

representing texts in electronic form. SGML is a meta-language, that is, 

a means of formally conveying a language, for specifying the structure 

and describing the content of documents. The use of SGML for encoding 

electronic forms ensures their transportability from one hardware and 

software environment to another without loss of information. SGML 

enables a publishers to define their own document formats and create a 

single document source that can be viewed, displayed, or printed in a 

variety of ways. 

XML is a sub-domain of SGML. The full specifications of SGML 

have a lot of unused and optional features that over time have proven to 

have a high cost/benefit ratio, especially for B2B type applications. 

XML removes many of those arcane and seldom-used features of 

SGML, making it easy to use for defining new document types and 

creating their own tags while freeing them from the constraints of using 

predefined tags. 

6.4.4. Sample XML files 

 

 

 

 

 

 

 



 

 


]> 

 

 

Publishers of the B2B Integration Book 

 

 

ABC Publishing Company 

staff@abcpublishing.com 

http://www.abcpublishing.com/ 

1900 East 32nd St. NY 10023 

212-111-1111 

212-222-2222 

 

 

Manning Publishing 

staff@manning.com 

www.manning.com 

30 Newport Parkway, Jersey City, NJ 07384 

201 533 0000 

201 533 9999 

 

 

XML allows user to: 

• define their own tags; 

• specify the semantics of the document; 

• form a single, logical compound file by bringing together multiple 

files; 

• provide processing information to the supporting application, like an 

XML parser, XML document validator or a browser; 

• have a secured exchange of data by using HTTP and HTTPS 

communication along with other security solutions;


• add editing comments to an XML file; 

• have faster searches and retrieval of documents, as it is easier to 

arrange XML into an indexed repository; and 

• Identify the location and format of illustrations in a text document. 

It is important to note, however, that XML is not: 

• A predefined set of tags that can be used to markup documents; or 

• A standardized template for producing particular types of text 

documents. 

6.4.5. XML strengths 

In this section, we will discuss the strengths of XML. 

Powerful meta-language 

Being a derivative of SGML, XML supports development of new 

markup languages for vertical industries and business domains. The 

XML language consists of rules that anyone can follow to create a 

markup language. Some of the examples include Fpml (Financial Products 

Markup Language), cXML (Commerce Extensible Markup Language). 

The rules ensure that a single compact program, the parser, can process 

all these new languages. XML can integrate multiple files (with structured 

data and unstructured data) into a single compound document. Example 

of structured data are legacy files or relational database, unstructured 

data can be text documents, graphics and images, audio and video 

resources and Web pages. 

Allows semantic agreement between trading partners 

XML enables the creation of semantic agreement among companies 

exchanging XML documents by providing a mapping, transformations 

and cross-references in that document. Through an XML workflow, 

which can be distributed to all the trading partners or can be on a perpartner 

basis, companies can also define the processing of this XML 

document by identifying activities, processes and tasks.


Domain-specific vocabularies 

XML enables building domain specific vocabularies for horizontal and 

vertical industry for, among others, advertising, financial and electronic 

commerce. These vocabularies will standardize the business process 

communication among partners. Several companies are also developing 

internal corporate vocabularies for describing internal data processes. 

Self-describing and interpreted 

XML is a human readable, self-describing language. Without any knowledge 

of applications and software programs at senders and receivers 

end, XML documents can be exchanged because the syntax of an XML 

document itself describes the relationships among the various elements. 

This relationship can be described either explicitly through Document 

Type Definitions (DTD) or implicitly by means of element context. The 

decoupling of applications and data also enables changes to the 

transactions, without any change required in the underlying applications, 

by merely changing the DTD. Proprietary as well as industry standard 

DTDs (XML/EDI, RosettaNet, etc.) can be used, depending on the 

requirement and availability. 

Simple 

Since XML is text-based, it is very easy to comprehend and understand 

XML documents, their structure, content, elements and relationships. 

This makes it easier to maintain and manage contents within XML 

documents. 

For example, if an XML document contains Orange and Orange, it is easy to distinguish 

that the first instance of Orange is in the context of fruit and the second 

occurrence is in the context of color. 

Separation of content data and its presentation format 

One of the biggest advantages of XML over HTML is that the former 

clearly separates the semantic content of the document and the 

presentation of the document.

Universal language 


XML is a universal language which can be used in possibly all 

applications, such as legacy systems, ERP, CRM, graphical user interface 

for applications, object-oriented applications in C++ and Java, databases 

such as Oracle, Sybase and ODBMS powered XML repository, to name 

just a few. 

Softwares that are properly coded to parse certain XML documents 

can even understand languages that use a different character set, like 

Arabic or Japanese. This enables the exchange of information, not only 

between different computer systems and applications, but also across 

languages and countries. 

Powerful XML-based search engines 

Since XML documents contain contextual information, XML-based 

search engines are more likely to retrieve exact results matching a 

search query. These search engines can also retrieve specific portions of 

an XML file rather than presenting the whole file to the user. This not 

only saves network bandwidth, but also gives faster access to relevant 

information for the user. 

Common open standard 

XML is based on common open standards, which decouples it from 

proprietary browsers, parsers, editors, etc. This is one of the great 

benefits of XML. 

Provides a 'one-server view' for distributed data 

In distributed applications, the data and elements that form an XML 

document can be distributed over multiple remote servers. Undoubtedly, 

XML is the most sophisticated format for distributed data. 

XML compresses very well 

Compression of data essentially means maximizing the throughput of a 

given input stream. Since XML documents are structured and highly


ordered, they can be compressed fairly well, thereby increasing 

performance. In fact, the compression of XML documents is much 

better than a standard text document as the latter is usually less structured. 

Rapid adoption by industry 

IBM, Microsoft, Sun, SAP, HP and many companies are supporting 

XML. XML is being rapidly adopted by all companies, big or small, in 

all the sectors of the economy, making it the de facto standard for 

exchanging data over the Internet. 

6.4.6. XML limitations 

In this section, we will discuss some of the major limitations of XML. 

XML messages can be very large 

XML messages can be as large as 5 to 10 times their equivalent EDI 

messages, making it much slower than EDI. Such a large flow of data 

over the Internet uses up a lot of network bandwidth and slows the 

whole process down. For large companies that have fixed relationships 

and high volume of transactions, EDI is still a better way of handling 

those connections. XML, on the other hand, can be used for seeking 

any-to-any connectivity. 

Different standards 

Several organizations and companies are promoting their own flavors of 

XML standards. This adds to a lot of confusion in the marketplace 

about the interoperability issues. XML is also just an evolving technology 

and there are several pieces that are still being developed. 

Limited semantic interpretation 

For two companies to be able to exchange XML-based data, they need 

to explicitly agree upon the semantics of the document such as the


definitions of tags. XML document by itself does not provide much 

information about how to interpret it. 

Does not facilitate data transformation 

The core problem in either EAI or B2Bi for all corporations is the 

ability to transform and integrate data from one application to another. 

However, XML is just another data format in the plethora of formats 

used by a company. 

6.4.7. XML namespaces 

According to the W3C, an XML namespace is a collection of names, 

identified by a Uniform Resource Identifier (URI) reference, which are 

used in XML documents as element types and attribute names. XML 

namespaces qualify element names in a recognizable manner to avoid 

conflicts between elements with the same name. The elements contained 

within an XML document can be defined in different schemas on the 

Internet. 

Since XML documents can contain data from multiple sources across 

the Web, there is a great likelihood of element name overlapping. With 

the use of namespaces, same element names will not conflict and 

clarify their respective origins within an XML document. In other 

words, these similar elements could refer back to different schemas 

which uniquely qualify their semantics. A very simple example of 

element repetition within an XML document is the use of in a 

book purchase order. This element can be used for the book title, 

author's title, publishing company's contact person title etc. It is worth 

mentioning that namespaces do not give processing instructions for 

elements. Users (application developers, etc.) have to know what the 

elements mean and decide how to process them. 

The W3C has released XML namespaces as a recommendation, 

allowing elements to be subordinate to a URI. This enables users to 

define private dictionaries of terms, or use a public namespace of 

common terms. 

Let's see the use of namespaces through an example.


XML NAMESPACE EXAMPLE 

 

 

 

 

Lee 

Bruce 

 

 

05-01 -2001 

l 111111 l 

 

 

Any element name that begins with 'buyer:' prefix 

defined by the 'http://www.ds.org/buyers' namespace. 

element beginning with 'gs:' has meaning defined by 

the 'http://gs.org' namespace. 

has meaning 

Similarly, any 

whoever owns 

6.4.8. Brief introduction to the components of XML 

Any XML document is composed of a series of entities, with each 

entity containing one or more logical elements and each element 

containing one or more attributes that describe how to process that 

entity. XML defines the syntax for expressing the relationships among 

entities, elements and attributes that together make up an XML document. 

Based on these relationships, applications identify the component parts 

of each document. 

The structure of an XML document is validated through XML 

schema or DTD that declares permitted elements, entities and attributes 

and their relationships. 

Elements and attributes 

The primary components described in a DTD are elements and attributes. 

Together they are responsible for establishing the logical structure of


XML documents. An element is essentially a logical unit of information, 

while an attribute is a characteristic of that information. Attributes help 

in describing the element in more detail. XML attribute types are of 

three kinds: a string type, a set of tokenized types and enumerated 

types. 

An element declaration has the following syntax: 

Syntax: 

 

Elements with data are declared with the data type inside parentheses: 

Syntax: 

 

#CDATA implies that the element contains character data (markup 

characters like 

The keyword ANY declares an element with any content. 

Example: 

 

Elements can also be empty: 

 

Empty elements are declared with the keyword EMPTY inside the 

parentheses. 

Example: 

 

XML element attributes are declared with an ATTLIST declaration. 

An attribute declaration has the following syntax:


Syntax: 

 

Attribute declaration example: 

DTD example: 

 

 

XML example: 

 

In this example, circle is defined to be an empty element with radius 

as an attribute of type CDATA. The radius attribute has a default 

value of 0. 

Entities 

XML documents are divided into storage units called entities, which 

define the physical structure of an XML document. The entities are 

usually identified by unique names and can be declared either internally 

or externally. Entities as variables can also be used to define shortcuts 

to common text. 

Following is the syntax along with an example: 

Syntax: 

 

DTD Example: 

 

 

XML example: 

&?writer;&copyright; 

Comments 

In XML syntax, comments begin with '' and can 

be placed anywhere in an XML document. Comments can contain any 

data except the literal string '--'. The parser does not usually pass 

comments to the application.

Document type definitions (DTD) 


An XML document is essentially a structured medium for storing 

information. But how does an application identify which XML document 

is valid or not? In order to assess the validity of an XML document, 

the application needs to establish exactly to which structure the 

information within the document must adhere. This is accomplished 

with a schema, which is a model used to describe the structure of 

information within an XML document. Schemas are used in XML to 

model a class of data. 

One of the principal uses of structured information is to enable data 

interchange. Different industries create consortia to specify the content 

model on which they all agree and which they use to mark up their 

information so that they can share it with each other easily and efficiently. 

In the context of structured information, that content model is defined 

as a DTD or a schema. 

DTDs are a means of establishing a schema for XML documents. 

The purpose of a DTD is to define the legal building blocks of an 

XML docment. It defines the document structure with a list of legal 

elements. A DTD can be declared inline in an XML document, or as an 

external reference. 

Example of a DTD: 

 

 

 

 

 

 

 

 

 

 

 




The DTD is interpreted like this: 

lELEMENT order (in line 2) defines the element 'order' as having 

a buyer element and one or more occurrences of 'lineltem' element. 

lELEMENT buyer (in line 3) defines the 'buyer' as having elements 

'name, address, city, state and zip'. 

!ELEMENT name (in line 4) is defined to be of the type 'PCDATA 

and so on ... 

Example of an XML document with an external DTD: 

 

 

 

]> 

 

 

Beautiful Home Departmental Store 

18 Middlesex Mall 

Edison 

NJ 

08817 

 

 

Hand-painted lamp 

50 

29.95 

 

 

Table-mat 

100 

5.95 

 

 

The file order.dtd contains the DTD.

XML schemas 


XML schemas, which are written in XML, define the complete structure 

(i.e., data types, elements, child elements, sequence of child elements, 

number of child elements, order of elements, attributes associated with 

elements, default values of attributes, entities contents and notations, 

etc.), content and semantics of XML documents. They provide valid 

building blocks for XML documents, support for data types and 

namespaces and document their own meaning, usage, and function. 

XML schemas are more flexible and powerful than DTDs. 

Validation of an XML document involves verifying the document 

against an XML schema. 




human-readable and machine-processable vocabularies designed to 

encourage the reuse and extension of metadata semantics among 

disparate information communities. The structural constraints RDF imposes 

to support the consistent encoding and exchange of standardized 

metadata provide for the interchangeabiUty of separate packages of 

metadata defined by different resource description communities. 

RDF integrates a variety of Web-based metadata activities including 

sitemaps, content ratings, stream channel definitions, search engine data 

collection (Web crawling), digital library collections and distributed 

authoring, using XML as an interchange syntax. RDF with digital 

signatures will be key to building the 'Web of Trust' for electronic 

commerce, collaboration and other applications. 

Source: www.w3.org/RDF 

6.4.9. Advantages of XML over traditional EDI 

Following are the advantages of XML over the traditional EDI: 

• Frees companies from the use of specific vendor software — With 

XML, companies can integrate business processes with their trading 

partners without having to use specific vendor software required for 

EDI. 

• Flexible standards — XML is based on simple, flexible and open 

standards, while EDI standards are very strict and inflexible. As a 

result, companies are able to automate the exchange of business 

information, dramatically improve efficiencies and reduce operating 

costs with the use of XML. 

• Cheaper — The initial setup and operational costs of EDI are very 

high. XML enables loose integration at a fraction of the effort and 

cost of traditional EDI. 

• Extensible — With XML, businesses do not need to replace or rebuild 

their applications; instead, they can simply XML-enable the data and 

systems they already have. 

• Human readable — XML is both machine and human readable while 

EDI is only machine-readable.


• Effective use of Internet — XML effectively uses the Internet to 

transfer the messages securely; whereas most of the EDI message 

flow occurs through expensive VANs. 

6.5. XSL — Extensible Stylesheet Language 

In order to display XML documents, it is necessary to have a mechanism 

to describe how the document should be displayed. One of the commonly 

used presentation technologies is Cascading Style Sheets (CSS) used by 

HTML, but XSL (Extensible Stylesheet Language), the preferred style 

sheet language of XML, is far more sophisticated than CSS. XSL is a 

language that can transform XML into multiple formats, a language that 

can filter, format and sort XML data and a language that uses XML as 

its syntax. Currently, XSL is used primarily to transform XML semantics 

into a display format like HTML that can be viewed through Web 

browsers. However, XSL provides a wide variety of presentation layers 

for a single XML document. 

An XSL style sheet contains instructions as to how to pull out 

information from the XML document and transform it into another 

format, such as HTML or PDF file. The transformation of XML into 

other formats is done in a declarative way rather than the conventional 

scripting way, which makes it much easier to understand and maintain. 

The browsers and devices such as PDAs (Personal Digital Assistants) 

and cell phones each have a unique display format. A single XML 

document can be presented on all these different presentation devices 

by using XSL. An XSL processor, either on the client or server, can 

transform XML data into the appropriate format, thereby completely 

decoupling the business layer with the presentation layer. This separation 

is the key to building any flexible and extensible application. 

An XSL processor can have output in multiple formats taking XML 

and style sheets (DTDs, schemas) as the inputs (see Figure 6.3). 

XSL consists of the following three parts: 

• XML Vocabulary — It describes the formatting objects portion of 

XSL. The process of formatting is performed by the formatter. The 

formatter may simply be a rendering engine inside a browser. 

Formatting objects can be inserted into a result tree created by


XML Document 

1 

XSL 

Stylesheets 

1 

1 

• XSLPi ocessoi' 

I 1 

HTML/ Cascading! 

Style Sheets J 

Postscript/ 

PDF 

Speech 

Figure 6.3. — A typical XSL processor 

" | 

Others 1 

another part of XSL, called XSLT, or XSL Transformations. Readers 

can get the most current working draft at http://www.w3.org/TR/xsl/. 

• XSL Transformations — This is a markup vocabulary which describes 

the transformation part of XSL. The input in this part is an 

XML document (source document) and the output is a result tree 

based on a series of filters and patterns that have been included 

within the style sheet. Readers can get the most current working draft 

at http://www.w3.org/TR/xslt. 

• The XML Path Language (XPath) — This is a language for 

addressing parts of an XML document, designed to be used by both 

XSLT and Xpointer. XSLT uses this language to describe the 

expressions and location paths that allow us to create expressions to 

manage the selection of nodes for more advanced XSL transformations. 

Readers can get the most current working draft at http://www.w3.org/ 

TR/xpath. 

Example of an XSL document: 

 

 

 

Order Example 

 

 

 

 

 

Buyer Details 

 

 

Order Line Item 

 

 

 

 

 


 

 

 

 

 

 

 

 

 

 

6.6. Coexistence of XML and EDI 


EDI has helped companies for the last several years to simplify and 

speed up their transactions with customers, suppliers and other partners. 

With the advent of XML, which has the potential of reaching new 

trading customers and markets and serves as a universal language for 

all types of transactions, companies are facing tough questions. Should 

we stay with EDI? Should we move to the evolving technology of 

XML? Should we try to get EDI and XML to intemperate? Have the 

XML standards been defined for our industry? 

In the following section, we will try to find the answers to these 

daunting questions that form the backbone of a B2Bi strategy. 

6.6.1. EDI is here to stay 

It is a misleading notion to claim that XML will completely replace 

EDI. It would be prudent for companies to build the XML world based 

on the last 30 years of EDI, rather than tear it all down. During these 

years, EDI has been implemented widely by large companies forming 

hub-and-spoke relationships. It has also been highly integrated into the 

core business processes of companies. This level of integration required 

considerable effort. It is absolutely not possible to undo all EDI from


business processes and then redo everything based on XML. XML and 

EDI will coexist for a long time. Their interoperability is one of the key 

success factors for large, medium and small size companies doing 

business on the Internet. 

For well-defined, repetitive and high-volume situations, utilizing 

existing EDI connections makes the most sense for the present, especially 

for large organizations. XML, on the other hand, can be used to make 

new contacts, such as participating in B2B exchanges and adding new 

trading partners. If a company's relationship with a new trading partner 

involves a very high volume of transaction, which is difficult to manage 

over the Internet, EDI can be used. This gives companies tremendous 

benefit in being able to develop the initial contact cheaply, see if that 

contact blossoms and then invest money in a more robust and expensive 

technology. 

What's likely to be used by companies is a hybrid of EDI and XML. 

Companies are already moving towards the implementation of EDI/ 

XML translation software that enables conversion of any XI2 or 

EDIFACT EDI document into the XML-based dialects (standards). The 

current XML dialects include xCBL, cXML, ebXML, BizTalk and 

RosettaNet PIPs. 

By the year 2003, XML/EDI will likely account for 30% of EDI 

transactions in the United States, with a further 30% supported via 

XML/EDI-to-EDI gateways. The remaining 40% will be supported via 

traditional EDI. 

6.6.2. EDI based on XML 

XML/EDI is an evolution, not a revolution. XML and EDI are both 

essentially data and metadata encapsulated in tokenized formats and 

structures. Thus, existing EDI structures and methods can be expressed 

in XML syntax and vice-versa (see Figure 6.4 and Figure 6.5). XML/ 

EDI can also seamlessly interface with existing EDI systems and provide 

100% backward compatibility. 

For instance, a company can send an EDI message in an XML 

format to a supplier. The supplier's system can pick up the message and 

show it in a browser to the individual responsible for approving incoming 

purchase orders. That individual can modify the incoming purchasing


X12 EDI 

IEDI -XML 

i Translator 

• Uses 

L\ 

XML —* XSL Parser frwnf 

XEDI XSL Parser XML 

Uses 

EDI Data Dictionary Transformation 

Instruction Sets 

Figure 6.4. — EDI to XML conversion 

Uses 

K 

EDI 


Rules Figure 6.5. — XML to EDI conversion 

order, which actually signals his approval — this could for instance be a 

digital signature. The approved purchase order can be sent back to the 

supplier's application as a plain EDI file. In this way, both human and 

machine readable messages that are created by a human or an application, 

can travel through an organization and can be sent to another organization 

and switch between humans and applications. 

It should be noted that one of the objections to wrapping an EDI 

message in an XML format is that a lot of overhead is created in the 

message. 

6.6.3. Characteristics of XML/EDI 

XML/EDI messages consist of a fusion of XML and EDI tags and data. 

They can be transmitted over the Internet like pure XML messages or 

over the VAN like EDI messages. All the current Web browsers that


support XML should also support XML/EDI messages. EDI information 

within an XML/EDI message is explicitly labeled using tag names. 

DTDs that contain the structure declaration and relevant sets of code 

values can be referenced over the Internet. 

XML/EDI is a fusion of many concepts. XML/EDI: 

• Uses the XML and XSL for data interchange and presentation 

respectively; 

• Provides a standard for formatting documents; 

• Can be integrated with traditional methods of Electronic Data 

Interchange (EDI) 

• Can be used with all standard Internet transport mechanisms such as 

IP routing, HTTP, FTP and SMTP; 

• Uses modern programming tools such as Java and ActiveX to allow 

data to be shared between programs; and 

• Uses agent technologies for data manipulation, parsing, mapping and 

searching. 

6.6.4. Benefits of XML/EDI over traditional batch EDI 

The benefits of XML/EDI over traditional batch EDI are: 

• XML/EDI is more dynamic, less costly and simpler than traditional 

EDI. It significantly reduces the entry costs for small and medium size 

companies, which cannot afford expensive EDI-based communication. 

• XML standards significantly reduce the number of trading partnerspecific 

maps required. 

• XML transforms static EDI tasks such as inventory management and 

production scheduling into dynamic processes, by using real-time 

XML-encoded information obtained directly from customers' and 

suppliers' business systems. 

• XML/EDI does not require extensive changes in the application layer 

which produces and consumes the data, as it keeps the information 

structure of EDI intact. The transition from EDI to XML using 

XML/EDI is done more at the transport layers. 

• The open architecture of XML allows the support of multiple 

standards.


• XML/EDI over the Internet offers companies cheaper e-commerce 

and smarter messaging via browsers. 

• XML/EDI enables contextual and intelligent searches over the Internet, 

as it wraps the unstructured text with structured data in the same 

document. This form of tagging makes the searches very efficient 

and accurate. 

6.6.5. Key features of XML/EDI server 

Does the server support all XML and EDI dialects? Is it scalable to 

manage high-volume relationships? How well will it be able to integrate 

with other existing systems? Does it provide secured and reliable 

messaging service? 

These are just a few of the questions that companies come across in 

their search for an XML/EDI server. EDI to XML translation and viceversa 

is achieved primarily through stand-alone software products. Several 

EDI vendors also incorporate XML translation functions. 

Here are just a few of the desirable features of XML/EDI server that 

a company should consider in its final decision. 

Support both XML and EDI-based trading partners 

XML/EDI server should support EDI as well as XML-based communication. 

This way, a company can establish newer contacts using 

XML-based messaging services over the Internet, while supporting 

existing EDI-based relationships. This kind of flexible data exchange 

would allow companies to achieve the best of both worlds. They can 

continue benefiting from their investments in integrated EDI systems 

while reaching small to mid-size enterprises and e-marketplaces with 

XML. The XML/EDI server should be able to convert XML documents 

into EDI documents and vice-versa, after validation and application of 

compliance checks and based on all major industry protocols. 

For example, it should support the following conversions: 

• XML to EDI, e.g., xCBL's Invoice to X12 810; 

• EDI to XML, e.g., xl2 850 to xCBL's Purchase Order; 

• XML to XML, e.g., xCBL to RosettaNet or xCBL to cXML; 

• XML to Flat File;


• Flat File to XML; 

• EDI to EDI, e.g., X12 to EDIFACT; and 

• Flat File to Flat File (including CSV format type). 

The server should support XML standards like xCBL, RosettaNet, 

cXML, Open Applications Group (OAG), Financial Information 

eXchange (FIXML), Financial Products Markup Language (FPML), 

Mortgage Industry Standards Maintenance Organization (MISMO), Open 

Travel Alliance (OTA). 

FASTENAL — MAKES NEW CONTACTS, 

WHILE MAINTAINING THE OLD ONES 

Fastenal Co. in Winona, Minn., a decade-long EDI user — thanks to 

the demands of its largest customer — the industrial and construction 

supplier knew that its existing system couldn't handle XML. Still, 

Fastenal needed to accept XML transactions to deal with portals and 

dot-coms. In addition, it wanted to unite its more than 600 branch 

locations with a common look and feel. And there was that pesky 

back-end connection. Seamless integration was of prime importance. 

Luckily, Sterling Commerce Inc. had the necessary back-end 

connectivity and XML capability. Sterling Commerce is mostly known 

for its traditional Gentran EDI products, but it also offers XML 

connectivity through some key partners. 

This illustrates an important point. Fastenal could have chosen an 

EDI/XML product and done the heavy lifting of integration from 

scratch. But by researching its needs more fully, the company was 

able to frame a better system for its situation. And by carefully 

investigating vendors, Fastenal discovered a technology set that would 

meet its needs far better and more simply than a homegrown solution. 

Source: Condensed from EDI? XML? Or Both?, Part 2, XML in Practice, ITWorld.com. 

Eliminate the need for using VAN services 

The XML/EDI server should eliminate the need for using Value Added 

Network (VAN) services by using the Internet for exchanging


transactions. The communication of data should be secured and reliable. 

This way companies can save a lot on the high transaction fees associated 

with exchanging transactions using third-party VANs. 

Fit in the bigger picture of B2Bi 

The XML/EDI server should include all the components necessary for 

seamless B2Bi. The server along with its components should be able to 

deliver automated, end-to-end integration between a company and its 

trading partners. It should provide ERP and EAI adapters and a robust 

business process engine for straightforward integration into the enterprise 

(see Figure 6.6). Since each company has its own integration challenges, 

the server should provide options for customization and integration. 

Support for business process integration 

XML/EDI server must integrate the business process transactions that 

involve inter-company data exchanges. Business process integration is 

one of the key requirements of the next generation XML-enhanced EDI 

servers. 

For example, when an ERP system detects low inventory and triggers 

a purchase order, the Netfish XDI Server automatically translates the 

XML/EDI Server Integrating Internal' and 

External Applications 

Exterrial Applications (Trading Partners, B2B Exchanges, Banks, 

Accounting, Purchasing, Finance) 

I I I 

EDIFACT mUD Proprietary 

! 

XML/EDI Integration Server 

EDI Data Flat File XML/DTD 

Internal Enterprise Applications ERP, Legacy Systems, CRM 

Figure 6.6. — XML/EDI server integrating internal and external applications

liS-i 

ERP XDI 

Server 

Trading Partner A 


VAN 

^XDI EDI 

Service •—-{fgp- internet 

Figure 6.7. Netfish XDI system 

Trading Partner C 

ERP business object into XML and deposits it in the trading partner's 

mailbox on the server (see Figure 6.7). The document is automatically 

scheduled for delivery to the supplier with the proper encryption and 

transaction audit trail. 

Supports encryption 

The data involved in B2B e-commerce is highly sensitive and should be 

protected from getting hacked or corrupted. The XML/EDI server should 

support encryption software to decrypt incoming data, encrypt outgoing 

data and authenticate both. 

Strong error handling 

Given the distributed nature of B2B applications, the XML/EDI server 

should have a robust error handling mechanism which captures all 

networking, application level and data errors. The error handling functionality 

should include the ability to capture errors in the error log and to 

notify the person(s) concerned. 

Allow trading partner configuration 

The XML/EDI server should provide an easy to use trading partner 

configuration tool. Through this tool, companies will be able to easily configure 

their trading partner profiles such as specific business documents,


formats and mapping guidelines, delimiter instruction, communication 

protocols and security protocols. 


XML has become the lingua franca of the B2B e-business revolution. It 

has created a mechanism to publish, share and exchange data using 

open standards over the Internet. There is no doubt that in the future 

XML will be used in each and every B2B application. 

XML is not an integration solution in itself—it is just a data 

definition language. Companies will have to install application integration 

servers that comply with all the leading XML standards and perform 

the traditional operations, such as routing, messaging, transformation 

and connectivity with databases and applications. 

In making a transition from EDI to XML-based communication, 

companies should try to leverage their existing hardware and software 

investments using an XML/EDI server. The XML/EDI server should 

enable companies to communicate with virtually any type of business or 

trading partner. This communication should be fast, secured and maintain 

data integrity. In all likelihood, they should be able to get an additional 

tool from their current EDI vendor that supports XML/EDI translation 

for all different dialects of EDI and XML.

Chapter ~~[ 

XML Standards for E-business 


B2B integration poses big interoperability challenges. Frameworks that 

provide standards and specifications for XML-based solutions for 

communication among cross-organization applications are critical to 

overcome these challenges. 

In this chapter, you will learn about the need for XML standards. 

We have presented a thorough discussion of the leading industry standards 

such as RosettaNet, ebXML and BizTalk with examples. You will also 

learn about the rapidly evolving Simple Object Access Protocol (SOAP). 

187


7.1. Standards Imperative for B2B 

Application Integration 

In the expanding world of B2B e-commerce, companies have to think 

globally. Without global e-commerce standards there can be no seamless 

business among companies spread out all over the world. These standards 

are a common set of industry-specific definitions representing business 

processes. For XML messages to be interpreted by all companies 

participating in B2Bi they need to agree on a common XML-based B2B 

standard, which will define the document formats, allowable information 

and process descriptions. These standards are like common currency for 

conducting business. If companies use the same currency to do business, 

then there is no need to convert one currency into another, based on 

today's conversion rate. In a similar way, communication based on 

these standards will be accepted and understood by every other company 

that uses the same standards. 

The need for industry-wide (vertical industries) B2B e-commerce 

standards is becoming increasingly critical and obvious. Several 

organizations have been working to define these market-segment-specific 

definitions. Standards such as RosettaNet and OASIS are making it 

possible for companies to share information with one another without 

having to completely re-engineer their internal applications. These 

standards will automate the flow of information across all companies in 

that industry, independent of the underlying software or hardware 

infrastructure supporting the activities related to these transactions. 

A few examples of B2B XML standards are: 

• RosettaNet — a collection of exchange protocols that define products, 

partners and business transactions for the electronic components and 

information technology industry; 

• Financial products Markup Language (FpML) — a standard for the 

financial industry; 

• Electronic business Markup Language (ebXML) — a joint initiative 

of the United Nations (UN/CEFACT) and OASIS, a set of 

specifications for XML-based messages that allow enterprises to 

conduct business with each other;

XML Standards for E-business 189 

• Commerce Extensible Markup Language (cXML) — a streamlined 

protocol intended for consistent communication of business documents 

among procurement applications, e-commerce hubs and suppliers; 

and 

• BizTalk Framework — a set of guidelines for implementing an XML 

schema and a set of XML tags used in messages sent between 

applications. 

In this chapter, we will discuss a few frameworks and standards 

that ensure data communication interoperability and provide a 

mechanism that allows enterprises to find and conduct business with 

one another. 

7.2. RosettaNet's Solution 

In this section, we describe RosettaNet — the leading B2B standard for 

the information technology, electronic components and semiconductor 

manufacturing industry. 

7.2.1. What is RosettaNet? 

RosettaNet is a consortium of major information technology (IT), 

electronic components (EC) and semiconductor manufacturing (SM) 

companies, including manufacturers, suppliers, distributors, resellers, 

financiers, shippers and end users, working to create and implement 

industry-wide e-business process standards. It is creating the electronic 

commerce framework to align processes in the IT supply chain. 

RosettaNet is establishing common definitions for data and business 

processes and dialogs in the supply chain cycle, such as quote and order 

entry and query product information. By defining these standard processes 

for the sharing of business information electronically, RosettaNet opens 

up the lines of communication for every company involved. It is one of 

the best examples of an industry standards group that is leveraging 

XML to address business needs.


7.2.2. Components of RosettaNet's 

e-business solution 

The RosettaNet e-business model consists of: 

• Partner Interface Processes — Business processes that define the 

interaction among trading partners; 

• RosettaNet Implementation Framework — A framework that defines 

protocol of networked applications; and 

• RosettaNet Dictionary — A set of dictionaries that provides common 

coding schemes and standards. 

Partner Interface Processes (PIP) 

RosettaNet aims to align business processes of supply chain partners 

by continuously developing, maintaining and distributing partner interface 

processes. RosettaNet's PIPs are specialized system-to-system XMLbased 

dialogs that define how business processes are conducted between 

IT manufacturers, software publishers, distributors, resellers and corporate 

end users. 

Each PIP defines how two specific processes, running in two different 

partner organizations, will be standardized and interfaced across the 

entire supply chain. PIPs include all the business logic, message flow 

and message contents to enable alignment of two processes. The partner 

companies can implement a subset of PIPs required to address their 

specific business interface requirements. 

Partner 

Review 

Establish 

Relationship 

Product 

Introduction 

Release 

Product 

Marketing 

Information 

Management 

Stimulate Market S. I 

Q'eate Demand I 

r 

Order i 

I nventory 

Management 

Management Service j I & 

Suppoit 

I 

Figure 7.1. — RosettaNet clusters 

Provide Post-Sate £ 

Support

3A Quote Si 

Order E ntry 

3B Transportation 

Et Distribution 

Shipping Instructions 

Snipping Status 

Quotes Purchase 

Oder 

3D Create Solution 

Configuration 

3C Returns 

& Finance 

Invoice Return Information 

Financial Authorization 


Sales Configuration 

"technical Configuration 

Ma n ufa ctu rin g In stru ctio ns 

Asse mb ly Instruct! on s 

3E Ship from Stock! 

& Debit /Credit I 

Credit/ Debit 

Authorization 

Figure 7.2. — Segments in Order Management cluster 

Table 7.1. PIP clusters and segments 

Cluster Segments 

1. Partner, Product and Service Review A. Partner Review 

B. Product and Service Review 

2. Product Introduction A. Preparation for Distribution 

B. Product Change Notification 

3. Order Management A. Quote and Order Entry 

B. Transportation and Distribution 

C. Returns and Finance 

D. Product Distribution 

4. Inventory Management A. Collaborative Forecasting 

B. Inventory Allocation and 

Replenishment 

C. Inventory Reporting 

D. Inventory Replenishment 

E. Sales Reporting 

F. Price Protection 

G. Ship from Stock and Debit/Credit 

(Electronic Components) 

5. Marketing Information Management A. Lead/Opportunity Management 

B. Marketing Campaign Management 

C. Design Win Management 

6. Service and Support A. Warranties Management 

B. Asset Management 

C. Technical Support and Service 

Management


The PIPs have been grouped in logical clusters (see Figure 7.1) and 

segments (see Figure 7.2) as shown in Table 7.1. 

A few published RosettaNet PIPs within clusters and segments are as 

follows: 

Note: For detailed description of PIP2A1, review Appendix A. 

Request Account Setup (PIPIAl) — PIPIAl provides automation support 

to the process of setting up an account between two trading 

partners, by electronically transferring information such as contacts and 

locations. 

Distribute New Product Information (PIP2A1) — PIP2A1 specifies 

the process of distributing new product information to buyers so that 

enterprise systems can accept product orders. It also specifies the 

process for product information users to populate the buyer's online 

sales catalog. 

Request Quote (PIP3A1) — PIP3A1 supports the process between 

trading partners that involves requesting and providing quotes. 

Notification of Sales Forecast (PIP4A1) — The purpose of PIP4A1 is 

to automate the process of issuing a sales forecast notification to a 

forecast recipient. The periodicity and time horizon of the sales forecast 

are customizable. 

Manage Sales Lead (PIP5A1) — PIP5A1 allows a sales lead originator 

to transfer the responsibility of working a lead to a sales lead processor 

who either accepts or rejects a lead. 

An example of a business scenario 

Consider a simple business scenario in which the buyer has to place an 

order with a supplier for a specific part. Both the buyer and supplier 

have implemented the RosettaNet Order Management process. This is a 

typical example of e-procurement using RosettaNet solution. 

The procurement cycle comprises of the following interactions 

between the buyer and supplier:


• The buyer confirms the price and availability for Item A with the 

supplier; 

• The buyer places the order with the supplier; and 

• The buyer checks on the status of the order. 

The PIPs that will be used in this example will be from the Order 

Management Cluster and Quote and Order Entry Segment as under: 

Query price and availability—PIP3A2 

With PIP3A2, the partners can query the price and availability of 

products from other partners that supply products in the supply chain 

(see Figure 7.3). Price and availability queries typically precede requests 

for quotes, as the quote is an agreement to provide a product at a 

specified price, whereas a price and availability check is much less 

formal. 

1. The buyer initiates the dialog with PIP3A2. 

2. The supplier acknowledges the request. 

3. The supplier sends the price and availability response back to the 

buyer. 

4. The buyer acknowledges the response. 

Quote and order entry — PIP3A1 

The purpose of PIP3A1 is to support a process between trading partners 

that involves requesting and providing quotes (see Figure 7.4). 

1.Price and availability query 

2. Acknowledges the request 

- 4 » " " 

i 3. Price and availability query response 

Buyer * -; Supplier I 

! -- 4. Acknowledges the response 

V- -/ 

Figure 7.3. — Query price and availability (PIP3A2)


Buyer 

Buyer 

1. Quote request 


3. Quote response 

4. Acknowledges the response 

Figure 7.4. — Request quote (PIP3A1) 

1. Purchase order request 

2. Purchase order acceptance 

Figure 7.5. — Manage purchase order (PIP3A4) 

!••• 

Supplier 

•1 

Supplier 

1. The buyer requests a product quote from a supplier using PIP3A1. 


3. The supplier responds back with the quote. 


Manage purchase order —PIP3A4 

PIP3A4 specifies the purchase order management process between trading 

partners (see Figure 7.5). The management process includes the creation, 

change and cancellation of a purchase order. 

1. The buyer creates a purchase order and sends a request to the 

supplier to fulfill the order. 

2. The seller acknowledges acceptance of the purchase order. 

3. The buyer can also use this PIP in the future to make a change in the 

purchase order or to cancel it altogether. 

J

k 

! . ^ . 

Buyer 

1.Purchase older status query 

4 


3. Purchase order status response 

4. Acknowledges the response 


— • 

• * • 

!••• 

Figure 7.6. — Query purchase order status (PIP3A5) 

Query order status — PIP3A5 

Supplier 

PIP3A5 specifies a process for querying and receiving the order status 

(see Figure 7.6). The status of the purchase order informs a requesting 

partner of the fulfillment and shipping status of the products in the 

order. For example, products in the purchase order request may be 

backordered, shipped, or the entire purchase order canceled. 

1. The buyer requests status of the product order. 


3. The supplier responds with the status that reflects the current state of 

the purchase order at the time of the request. 


RosettaNet implementation framework 

The RosettaNet implementation framework is an open and common 

framework for partners and solution providers to implement computer 

solutions that can collaboratively execute RosettaNet complaint PIPs. 

Its specifications include authentication, authorization, encryption and 

non-repudiate implementation aspects that are necessary for conducting 

secure electronic business over the Internet. 

This framework enables the creation of networked applications across 

corporate boundaries and executes electronic business processes by 

communicating via strictly defined protocols. 

\ 

D>


RosettaNet dictionary (ITTD) 

RosettaNet dictionary is a master dictionary, which defines the properties 

for products, partners and business transactions. This dictionary, coupled 

with an established implementation framework, is used to support the 

e-business dialog known as PIP. 

The dictionary captures the component characteristics, component 

features and component associations. Characteristics are quantitative 

properties that have a well-defined type and default unit of measurement. 

Features are qualitative properties that may be single or multiple valued. 

The dictionary enumerates the set of valid features if they exist. 

Characteristics and features together are called as resources of a 

component. 

The following terms are used in specification names to denote 

component resources: 

1. Supplies: A component supplies a resource, e.g., a memory module 

and hard disk 'supply' storage capacity. 

2. Consumes: A component consumes a resource, e.g., software 

'consumes' storage capacity when it is permanently stored on hard 

disk. 

3. Uses: A component uses resources in a shared way, e.g., software 

'uses' temporary disk space; other programs use this space as well. 

In addition, dictionaries capture the enumerated set of valid feature 

values that exist. Associations imply component interrelationships 

necessary for describing complex products. These are also present in 

the dictionary. Apart from all the above, the dictionary contains 

component functional or operational property specifications, such as 

resource consumption characteristics and functional architecture 

associations. Finally, the dictionary contains constraint descriptions that 

define the boundary conditions within which complex products can 

operate. For example, a laptop provides a minimum of 1 and a maximum 

of 1 serial port. 

7.2.3. Benefits of using RosettaNet solution 

The benefits of using RosettaNet-based B2B integration solution 

include:


• Manufacturers and distributors will accelerate the speed of product 

availability to the buyers, decrease their inventory levels, raise 

productivity, have faster response times and thus be cost effective. 

• Using RosettaNet's electronic component technical dictionary (ECTD), 

manufacturers can make an immediate announcement of a new product 

and discontinuation of an existing product to all buyers and B2B 

exchanges. This is especially relevant in an industry where the 

product life cycles are very short. 

• RosettaNet PIPs ensure the accuracy of transmitted data, eliminate 

redundant data entry at multiple points in the supply chain and 

facilitate more accurate planning and forecasting than before. 

• RosettaNet helps in streamlining just-in-time (JIT) reporting among 

all partners in the supply chain cycle. Usually the cost of generating 

multiple reports for multiple trading partners is very significant. 

Companies can reduce this cost as the product definitions become 

standardized. 

• Buyers can do a comparative study and analysis of the different 

product lines from multiple vendors. RosettaNet makes the information, 

like the catalogs, available to buyers in a uniform format from 

suppliers, making it possible for buyers to do an orange-to-orange 

evaluation of the product pricing, contract terms, availability and 

delivery dates. 

• Based on the above-described uniformity, buyers can shorten their 

procurement cycle and make it standardized. 

• Buyers and sellers will not be married to each other for a lifetime. 

They can engage in dynamic, flexible trading-partner relationships. 

• RosettaNet also standardizes the money lending process between 

partner companies and financial institutions. All the lending processes 

can be tracked on a real-time basis. 

To exploit the benefits of standardization, RosettaNet solution has to 

be widely adopted and integrated into enterprise applications by all 

large companies (if possible — all companies) in the respective sectors. 

7.2.4. RosettaNet embraced by software vendors 

Several leading software and application server vendors in the B2B 

space are providing packaged solutions to help companies implement


RosettaNet PIPs for the RosettaNet Implementation Framework (RNIF). 

This capability reduces B2B integration complexities by providing 

baseline rules and standard message formats for trading partner 

interaction. 

A good example is WebLogic Collaborate for RosettaNet which 

provides tools to help solution providers implement PIPs. 

7.2.5. What's the ROI (Return on Investment) in 

implementing RosettaNet solution? 

The return on investment is probably the first question that any 

corporation would consider before investing any resources to implement 

RosettaNet. Just because it is a hot technology and has everyone talking 

about it, is certainly not a good enough reason. How much companies 

will have to invest in implementing this solution and what the payoff, 

both near term and long term, are natural questions that need to be 

answered. 

There is little doubt that the first PIP is the hardest to implement. The 

cost and difficulty level in business process reengineering and integration 

is high. However, both these features fade away with the implementation 

of subsequent PIPs. The companies can, thereafter, enjoy the fruits of 

incremental cost reduction inherent in XML-based standards. The 

implementation and integration cost and effort required in RosettaNet is 

inversely proportional to the level of integration in existing systems. 

According to RosettaNet, implementation of just one PIP that allows 

manufacturers to seamlessly add new products — including standardized 

technical specifications and part numbers — into their partners' catalogs 

alone, results in an average of $1 million in cost savings per year for 

each implementer — a 200% ROI. The IT supply chain stands to reap 

significant savings from the pervasive implementation of PIPs, possibly 

as high as $25 billion annually. 

Philips Semiconductors, a member of RosettaNet, believes that 

RosettaNet's operational process enhancements will save the company 

millions of dollars. Just by allowing customers to view order status and 

obtain cursory price and delivery information in a standardized way, the 

company will reduce the amount of customer service-related calls by 

75%.

Leverage existing assets 


Companies will be able to lower their investment cost in implementing 

RosettaNet solution by building it on top of their existing assets. If a 

company has invested millions of dollars to put their EDI infrastructure 

in place, it makes absolutely no sense to abandon it and embrace 

RosettaNet. Instead, it should find an application server or software 

that, apart from supporting all RosettaNet PIPs, is also able to connect 

to its EDI systems. For example, XMLSolutions' software and services 

support all RosettaNet PIPs. The integration of XMLSolutions' XEDI 

with RosettaNet provides a means to connect with existing EDI systems. 

ROSETTANET TRANSFORMS HEWLETT-PACKARD'S 

SUPPLY CHAIN 

Hewlett-Packard's implementation of RosettaNet PIPs has transformed 

HP's B2B processes throughout its supply chain for HP workstations, 

HP NetServers and Unix servers. The RosettaNet PIPs have resulted 

in significant time savings and a smoother information flow for HP 

and its value-added resellers (VARs), distributors and contract 

manufacturers. 

All the three RosettaNet PIPs that HP is currently using — PIP3A4, 

which acknowledges receipt of a purchase order; PIP3A6, which 

provides order status; and a pre-release version of PIP3B2, which 

sends advance shipment and shipper's manifest notifications — have 

reduced processing time for HP and North American VARs and 

distributors from days to minutes. At the other end of the supply 

chain, the same PIPs are being exchanged between HP and North 

American contract manufacturers, resulting in similar time savings. 

The HP NetServer division is also using RosettaNet to enable 

VARs to streamline their entire configuration, pricing and availability, 

checking for HP NetServers ordered under HP Select Express, which 

delivers customized solutions. 

The key benefits of implementation include: 

• Easy-to-use, Web-based toolset for Select Express HP NetServers; 




• Quick and accurate HP NetServer configuration and management 

of shopping carts; 

• Online access to distributor pricing and HP availability for VARs; 

• Easy, customized quote creation for customers; and 

• Fast online order placement direct to distributors. 

Source: Condensed from RosettaNet Standards: Strengthening Trading Networks, 

Ascet Volume 3 

7.3. FpML — Financial Products Markup Language 

This section gives a brief description of the Financial Products Markup 

Language (FpML) and its benefits. 

7.3.1. What is FpML? 

FpML is a new protocol, based on XML, to enable e-commerce activities 

in the field of financial derivatives. It is a standard that will allow 

financial institutions to exchange derivative transactions using the 

Internet. All categories of over-the-counter (OTC) derivatives will 

eventually be incorporated into the standard. It aims to streamline the 

processes supporting trading activities in the financial derivatives, by 

describing these products and associated business interactions, based on 

industry standards (see Figure 7.7 and Figure 7.8). 

7.3.2. Benefits of FpML 

The benefits of using FpML include: 

• Trade automation; 

• Enable sharing of financial information among disparate financial 

applications; 

• Faster trade confirmations; 

• Lower cost of system implementation and communication between 

applications, resulting in an overall decrease in transaction cost;

Trade Pricing 

Confirmation 

System 

Settlement 

System 

Collateral 

Management 

System 

Manual 

Matching 

Mddle Office Middle Office 

I 


"Had 

I Ticket! 

Confirm Confirm I 

Reconciliation 

Setdement 

Collateral 

Matching 

1 L 

Confirmation 

System 

Setdement 

System 

Collateral 

Management 

System 

Figure 7.7. — Current manual process utilized for derivatives trading 

FpML -rj.a[|e pricing 

System 

FpMLRisk Managementj 

System 

5 ^ Settlement 

System 

FpML Collateral 

4mm^> Management 

System 

FpML 

Settlement 

FpML 

Trade Pricing 

System 

Risk Management! 

System 

Settlement 

System 

Collateral 

Management 

System 

FpML 

FpML 

FpMLI 

FpML 

Figure 7.8. — Automated process for derivatives trading using FplvIL 

11


• Easy procedure of adding new trading partners like counterparties; 

and 

• Reduce operational risks while increasing business opportunities for 

the wholesale financial services. 

7.4. Commerce XML (cXML) 

cXML is an open Internet-based standard for e-commerce. It is a set of 

lightweight XML DTDs — based on the World Wide Web Consortium's 

XML standard — with their associated request/response processes. 

cXML reduces online business trading costs by facilitating the exchange 

of content and transactions over the Internet. cXML provides an 

infrastructure for digitally exchanging catalog content and transactions 

in a secure manner. cXML supports all supplier content and catalog 

models, including buyer-managed, supplier-managed, content management 

services, electronic marketplaces and Web-based sourcing organizations. 

This allows suppliers to provide customers with selective access to 

personalized catalog content while maintaining their unique branding 

and competitive differentiation. 

cXML defines a request/response process for the exchange of 

transaction information. These business processes include purchase 

orders, change orders, acknowledgments, status updates, ship notifications 

and payment transactions. 

cXML also has a lower cost of implementation because of its XML 

base and ability to leverage existing HTML e-commerce infrastructure 

and software. For example, cXML leverages suppliers' existing 

e-commerce capabilities by allowing buyers to access supplier Websites 

from within a buy-side application. Using this functionality, buyers can 

see their contracted items, private prices and access product configurators 

or libraries of products. Since cXML is Internet-based, it provides a 

more cost-effective alternative to EDI and other methods of exchanging 

catalog content and transactions. 

Following are the main types of cXML documents: 

• Catalog — used by suppliers to convey product and service content 

to buyers.


• PunchOut — used to implement protocol for interactive sessions 

between applications managed across the Internet by using real-time, 

synchronous cXML messages. 

• Purchase Order — used by buyers to send purchase orders to suppliers 

to request fulfillment of a contract. 

Example of cXML-based Contract document: 

 

 

 

123456 

 

A sample cXML Contract Document 

 

 

 

 

AB1234 

 

100 

http://www.gsdscom/book 

 

 

 

AB5678 

 

150 

 

 

 

This cXML document is based on: 

http://xml.cXML.org/schemas/cXML/L2.006/cXML.dtd


7.5. Electronic Business XML (ebXML) 

ebXML is a set of specifications that together enable a modular, yet 

complete electronic business framework. ebXML is a complete set of 

specifications to enable secure, global, electronic business using proven, 

open standards such as TCP/IP, HTTP and XML. It is a joint initiative 

of the United Nations (UN/CEFACT) and OASIS. 

Conducting electronic business with ebXML is essentially a fourstep 

process (see Figure 7.9): 

1. Design and register business processes and information models; 

2. Implement business service interfaces and register; 

3. Optionally negotiate and define a Collaborative Partner Agreement 

(CPA); and 

4. Exchanging messages between business partners. The software 

applications send and receive ebXML messages containing ebXML 

business documents, over the secure and reliable ebXML messaging 

service. 

Implement & 

Register Profile 

Optionally Negotiate 

Agreement 

Hi. 

'.V= £|I Industry 

- »j" ""• Group 

Q Business FVocess Bt 

Design and Register Process Information Model 

Trading Partner i 

profile f""""" 11 *" 

Company A 

h Trading 

Conduct ebXM. Business 

Registry/ 

Repository 

Partner 

Agreement 

• Business Document 

Figure 7.9. — Four easy steps to ebXML 

TTading Partner 

Profile 

I 

Company B


7.6. Simple Object Access Protocol (SOAP) 

In order to accomplish B2Bi over the Internet, applications of multiple 

trading partners have to communicate. In the past, this was accomplished 

using distributed component architecture such as CORBA and DCOM. 

However, such architecture does not leverage the Internet, as it is based 

on remote procedure calls (RPCs), which can cause a substantial security 

threat over the Internet and usually the corporate firewalls and proxy 

servers block such traffic. 

SOAP is ideal for B2B applications, since it is an XML-based 

protocol for exchange of information over the Internet in a decentralized, 

distributed environment. 

It consists of three parts: an envelope that defines a framework for 

describing what is in a message and how to process it, a set of encoding 

rules for expressing instances of application-defined datatypes and a 

convention for representing remote procedure calls and responses. 

7.6.1. SOAP messages 

All SOAP messages are encoded using XML. The SOAP message, 

essentially an XML document, contains the following XML elements 

(see Figure 7.10): 

• A SOAP envelope, which is the top element of the XML document 

and defines the contents of the message. 

• A SOAP header that contains header information. This element is 

optional. The header is a generic mechanism for adding features such 

Figure 7.10. — Components of a SOAP message


as authentication, transaction management, payment, etc. to a SOAP 

message in a decentralized manner without prior agreement between 

the communicating parties. 

• A SOAP body, which contains mandatory information, intended 

for the ultimate recipient of the message. It contains both call and 

response information. 

HTTP Request Message 

EXAMPLE MESSAGE 

 

 

 

 

SUNW 

 

 

 

This SOAP message will be embedded in the HTTP request. The 

description of the document is as follows: 

1. The envelope is the first element of the XML document. 

The namespace prefixes "SOAP-ENV" and "SOAP-ENC" used 

in this document are associated with the SOAP namespaces 

"http://schemas.xmlsoap.org/soap/envelope" and 

"http://schemas.xmlsoap.org/soap/encoding/">. 

2. The namespace for the function (s) is defined at 

"http://www.getstock.org". 

3. GetStockQuote request is sent to the server. The request has a 

StockSymbol parameter with the value SUNW. 


HTTP Response Message 




BizTalk Framework Compliant (BFC) Server 

A BFC server is represented by the set of services providing the messageprocessing 

functionality defined in the BizTalk Framework specifications. 

Note: BizTalk Server, one of the commercial BFC Servers available, is 

discussed in the chapter on integration brokers. 

Application 

An application is the line-of-business system where the business data or 

logic is stored and executed. Examples of application are ERP systems, 

CRM systems, etc. An application also includes any additional adapters 

that may be required to emit or consume business documents and 

communicate with a BFC server. 

Business document 

A business document is a well-formed XML document containing 

business data. This data may represent a purchase order, invoice, sales 

forecast, or any other business information. 

7.7.2. The envelope 

The communication between BizTalk servers is through BizTalk 

messages, which are envelopes of multi-layered objects (see Figure 7.11). 

Transport Envelope 

BizTalk Document 

BizTalk Header 

Delivery Information 

• Document Manifest '• 

Document Body 

Bu siness. Dot umfent • 

..iAU-"*, %--«!**•,* 

Figure 7.11. — BizTalk envelope structure


The first layer specifies the transport mechanism such as HTTP and 

FTP for this specific object and acts like a wrapper to the BizTalk 

document. A BizTalk message always contains a primary BizTalk 

document. This document defines the semantics of the message within 

the BizTalk Framework and it is actually a SOAP 1.1 message, i.e., it 

contains an optional header element and a mandatory body element. 

The information for the recipient of the message is contained in the 

body of the message and can be any business document, such as a 

purchase order and request for quote. 

BIZTALK DOCUMENT EXAMPLE 

1 

2 

< !—The header, an optional field, defines details for the message 

envelope—> 

3 

4 

5 

6 12032000 

7 2001-03-12T12:15:30+01:00 

8 Purchase Order 

9 

10 

11 http://www.gsds.com/purchase_order.jsp 

12 

13 DRAM 

14 order 

15 PurchaseProcess 

16 

17 

18 

19 mailto:eprocurement@gsds.com 

20 

21 DRAM 




22 order 

23 ConfirmProcess 

24 

25 

26 

27 

28 

29 PurchaseOrder_DRAM 

30 Purchase Order for DRAM 

31 

32 

33 l 

34 PO.sig 

35 This is digital signature file 

36 

37 

38 

39 

 

40 

41



2 — biztalk_l is the root element of this XML document. There is 

also a namespace associated with the document, which is essentially 

a Universal Resource Name (URN). It indicates the location of the 

schema that describes this document. 

3 — 38 — The header node of the document contains delivery and 

manifest as child nodes. The delivery element is required to provide 

the routing/delivery information. The manifest element describes what 

is being sent in this document and can include attachments. 

4 — 26 Delivery element which contains message, to and from as 

child nodes. 

6 — Unique message ID associated with this document. 

7 — TimeStamp indicating the time when the message was 

sent. 

8 — The subject specifying the title of the message. 

10 — 17 — element which contains address and state as its sub 

elements. This provides information to the sender's BizTalk server to 

route the above document. 

11 — Address of the receiver's BizTalk server. In our 

example, we are sending the document to www.gsds.com. The address 

also contains information about the action to be taken on the receiver's 

server. In this example, we are causing it to execute purchase_order.jsp 

on that server. 

12 — An element that contains , 

and as the sub-elements. They describe how the BizTalk 

server has to process this document. 

18 — Same as element, but provides information about 

the senders BizTalk server and the processes that will handle the 

response. 

19 — The response BizTalk document will be routed to 

the ConfirmProcess through the mail server. 

27 — 37 — An element that contains and 

as sub-elements. 

28 — has and as its sub-elements. 

32 — 36 — An element that has , and 

as the child nodes. Together they describe the attachment 




that is accompanied with this BizTalk document. In this example, we 

are sending a digital signature file to make sure that the submission 

of Purchase Order is secured. 

39 — 43 — The body element contains BizTags that together 

define the purchase order. The purchase order sent in this BizTalk 

document is based on PurchaseOrder_DRAM.xdr schema. Also 

provided is the information about the namespace of this schema, 

which in this example is located on the sender's server. 


B2B integration poses big interoperability challenges. Frameworks that 

provide standards and specifications for XML-based solutions for 

communication among cross-organization applications are critical to 

overcome these challenges. 

There are several vertical-domain specific standards bodies and 

industry initiatives to specify vocabularies and content models for 

XML-based solutions like schemas. These schemas are becoming widely 

published and implemented to facilitate communication between both 

applications and businesses. 

However, several of these standards are doomed to fail. It is very 

important for a standards body to align with all the major companies in 

that vertical industry or it will not find support from the leading 

software vendors for their standards. The standards body should try 

'not' to overdo the specifications for business processes. This will 

avoid delays and complexity in their specifications.

Chapter 8 

Middleware Technologies 


Middleware technologies advance the goals of B2B integration and 

enterprise application integration. By integrating disparate systems 

throughout an organization, middleware technologies can promote a 

zero-latency enterprise strategy where data is exchanged across systems 

in real-time; reduce application development time and improve speed to 

market; create standardized development methodologies throughout an 

organization; facilitate the integration of systems inherited through 

mergers or acquisitions; and reduce application maintenance. 

In this chapter, we have presented an introduction to all the leading 

middleware technologies, including message oriented middleware — 

MQSeries, JMS and MSMQ, transaction processing monitors, distributed 

components middleware — CORBA, Windows DNA and J2EE. You will 

also get an overview of the leading J2EE-based application servers — 

BEA's WebLogic and IBM's WebSphere. 

213


8.1. What is Middleware? 

The term 'middleware' is actually a misnomer to a large degree. 

Middleware has typically been defined as distributed software that 

resides in the middle of a client/server system providing a uniform 

'conduit' for client applications to communicate with a server. The 

truth is that many middleware products manage, contain and share 

business and application logic, operating more as a server than as 

'middleware'. 

Traditional middleware technologies include message oriented 

middleware (MOM), TP monitors and distributed object technology, 

though a 'purer' type of middleware would be communication conduits 

such as TCP/IP, DCE and RPC. Middleware products provide a highlevel 

abstraction through an API that shields a developer from the 

complexities of heterogeneous platforms and architectures. 

In order to accomplish the transfer of information, most middleware 

will follow a standard set of functions as under: 

• The sending application formats the information into a message 

buffer using a process called marshalling. 

• The sending application must identify the location of the receiving 

application or service. The destination can be specified several ways 

including: 

1. Hard coding; 

2. Initialization file; and 

3. Middleware naming service such as JNDI or UDDI. 

• The sending application must initiate a network communications 

session with the destination application. 

• The sending application must transfer the message buffer to the 

receiving application. 

• The receiving application must receive the message buffer. 

• The receiving application must extract and interpret the information 

in the message using a process called unmarshalling. 

• If a response is required, then the receiving application must generate 

a response and repeat the communication process to send a message 

back to the sender.

Middleware Technologies 215 

The various types and classes of middleware are extensive and 

cannot be covered completely in one chapter. Therefore, this chapter 

provides an overview of the most popular middleware technologies, 

including: 

• Transaction Oriented Middleware; 

• Message Oriented Middleware; and 

• Distributed Objects and Components. 

Transaction Oriented Middleware — This middleware technology 

includes transaction processing (TP) monitors and transactional-based 

application servers. TP monitors were the first true middleware application 

servers. A transaction processing (TP) monitor is middleware that 

manages transactions, processes, or applications from multiple clients 

across multiple servers. 

Generally, these transactions are carried out on database servers but 

can also be process-based. Some functions performed by TP monitors 

include prioritization, resource funneling, connection pooling, highavailability 

and load balancing. TP monitors are mature, stable, battletested 

middleware solutions. IBM's CICS is a TP monitor which has 

been around since the 1960s. 

Message Oriented Middleware (MOM) — MOM is an integration model 

that connects applications running on different systems by sending and 

receiving application data as messages. The application data is combined 

with a header (information about the data) to form a message. 

MOM is an asynchronous model providing a loosely coupled 

communication between the client and server. There are two primary 

MOM frameworks: point-to-point and hub-and-spoke (brokering). The 

emergence of the hub-and-spoke model of message brokering offers 

substantial benefits over the traditional point-to-point model message 

queue. 

Distributed Objects and Components — This middleware technology 

allows objects and components, distributed throughout servers within an 

enterprise, to interoperate and share functionality. Client objects and 

components invoke the public methods of server objects and components 

providing business method level integration.


Distributed object technology is very well suited for heterogeneous 

systems and architectures which exist in most organizations. Distributed 

objects encapsulate the business logic and data within objects, allowing 

them to be located anywhere within a distributed system. Objects can 

be linked together in a plug-and-play manner to interoperate across 

networks. 

These three middleware solutions provide the foundation for today's 

enterprise middleware frameworks. Middleware technologies are 

converging and morphing into middleware frameworks, which can 

manage the integration needs of an entire enterprise. Throughout this 

chapter, you will see words such as 'convergence', 'morphing' and 

'framework' mentioned repeatedly. 

8.2. Transaction Processing (TP) Monitors 

To understand transaction processing monitors, one must first understand 

a transaction. A transaction is defined as the execution of a unit of 

work that either succeeds or fails as a whole. If one part of the 

transaction were to fail, the entire transaction would rollback to 

its initial state. Transactions are usually associated with database 

transactional methods. A transaction begins with a 'Begin Transaction' 

and ends with either a 'Commit Transaction' if successful or a 'Rollback 

Transaction' if there is an error. Transactions are always an all-ornothing 

proposition. 

A transaction becomes the fundamental unit of recovery, consistency 

and concurrency in a distributed environment. A transaction is a 

collection of actions that must also maintain its ACID properties. ACID 

stands for: 

Atomicity — A transaction is an indivisible unit of work. It will succeed 

or fail as a whole. If a transaction fails, all the steps will be rolled back 

to the initial state. Otherwise, the entire transaction will be saved 

(committed). 

Consistency — After a transaction executes, it must leave the system in 

a correct state or it must abort. If it cannot achieve a consistent state, it 

must rollback to its initial condition.


Isolation — A transaction's behavior is not affected by other transactions 

which are occurring concurrently. This is often accomplished by 

serializing transactions by using table or row level locking within a 

database. 

Durability — A transaction's effects are permanent after it commits, 

even in the event of a system failure. 

TP monitors allow multi-vendor resources to plug into the TP system 

and provide global management of transactions across databases and 

other resources. TP monitors are still unmatched in the management of 

high transactional environments across multiple database systems residing 

on multiple operating systems. 

8.2.1. How they work? 

TP monitors decouple the relationship between the client application 

and the physical database schema. Access to the underlying database is 

usually through an API, ensuring enforcement of business rules and 

referential integrity. By offloading most work to a middle tier, TP 

monitors improve overall system efficiency. 

TP monitors work by creating classes or application processes, 

which are memory-resident threads that handle the work for a particular 

application. Each application can have one or more classes 

belonging to it. When a client requests a service from the TP monitor, 

the server loads the DLL for the process, manages the execution of the 

process or transaction and returns the results to the client. The DLL can 

then remain resident in memory where it can be shared by other 

processes. 

Due to the inherently heterogeneous environment in which TP 

monitors exist, a set of standards was developed to allow these products 

to communicate with disparate systems. In 1991, the X/Open XTP group 

published the Transaction Processing Reference Model, often referred 

to as the X/Open XA model for transaction managers. 

The standard defined three components for transaction processing 

are:


• Resource Managers — the component which manages shared 

resources. They are responsible for ensuring that changes to the 

datastore are executed in a consistent, isolated and durable manner. 

• Transaction Managers — the component which is responsible for 

managing and coordinating resource managers and coordinating a 

transaction with other transaction managers. 

• Application Programs — the application which uses the resource 

manager to coordinate and manage its transactional needs. 

8.2.2. Benefits of TP monitors 

The benefits of the TP monitors include: 

Three-tier architecture 

TP monitors support the concept of n-tier architectures by decoupling 

the client application from the underlying datastore. They promote the 

use of reusable, encapsulated components and enforce the ACID 

properties of each transaction. 

Prioritization 

Each application can have one or more classes belonging to it. Each 

class can also be prioritized. Typically, short-running, high-priority 

processes are assigned a high priority status while batch and lowpriority 

processes are assigned a lower priority status on the server. 

Load balancing 

One of the biggest benefits of TP monitors is the ability to provide both 

static and dynamic load balancing. If the load on the server becomes 

too great, a TP monitor can dynamically create new processes or 

distribute the load to other servers. TP monitors can also make effective 

use of a multi-processor (SMP) machine. 

All major database vendors provide some TP monitor capabilities 

within their flagship databases, but these transaction monitors generally


provide a single-domain, single-vendor solution for transaction processing. 

Stored procedures and triggers in single-vendor database environments 

now handle many of the transactional duties that used to be performed 

by TP monitors. However, these solutions lack such benefits as loadbalancing 

and prioritization found in traditional application servers and TP 

monitors. These vendor specific TP solutions can also prove inadequate 

when considering that the typical Fortune 500 company has dozens of 

separate databases based on four or more different database products. 

TP monitors are a necessity in most database-centric integration 

solutions. The major middleware vendors have not overlooked this fact 

as the lines between application servers, distributed objects and TP 

monitors are quickly becoming blurred. 

A few leading vendors for transactional middleware include BEA's 

Tuxedo, IBM's CICS and Microsoft's MTS. 

8.3. Message Oriented Middleware (MOM) 

MOM is an integration model that connects applications running on 

different systems by sending and receiving application data as messages. 

MOM is an asynchronous communication style that provides a loosely 

coupled exchange across multiple operating systems and disparate 

applications (see Figure 8.1). 

Sender Receiver 

Application A 

Message 

Application B 

Message 

Message! • 

Sent! 1 Message 

ip> (Received 

Queue Manager 

Middleware Ads 

as Mediator 

Figure 8.1. — Asynchronous communication using message oriented middleware


The typical MOM system contains the following components: 

• Messages; 

• Queues — the physical MOM server; and 

• Messaging Clients — the sender and receiver. 

Messages — Messages generally consist of two parts: a header and a 

body. The header contains information to route and identify each message. 

The body contains the application data or message content. Messages 

can be assigned priorities so that higher priority messages can be 

processed before lower priority messages, improving overall system 

performance. 

Queues — Queues are the mailboxes or inboxes of MOM. Queues 

receive and store messages until the receiving applications are ready to 

retrieve each message. Queues may be physically located on the sending 

computer, the receiving computer, or both. 

Queues are managed by a message queue server that is independent 

of either the application client or application server. The server may 

also manage several queues on one host machine. 

Queues may be persistent or non-persistent. Non-persistent queues 

store messages in memory, which means that if the message queuing 

server fails messages could be lost. Persistent queues will write messages 

to a physical disk, ensuring that they can be recovered in the event of a 

server failure. 

Persistent queues can provide guaranteed delivery of messages. 

Guaranteed delivery can be beneficial where the reliability of the 

network or applications themselves cannot be guaranteed. Persistent 

queues typically require more resources and can be slower than nonpersistent 

queues, but are often a necessity in most critical business 

applications. 

Message Clients — Message clients reside with client applications and 

provide an API to allow the application to send and receive messages. 

Using the API, an application is able to initiate a session, prepare a 

message, set routing parameters and send messages to the intended 

queue.

8.3.1. Why use message queues? 

The advantages of using message queues are as below: 

Asynchronous communication 


In the RPC model, a client sends a request to a server, waits for the 

server to run the procedure and return a reply, all strictly a synchronous 

process. If there is ever a problem with the server or a break in the 

network connection, the client can face two possible outcomes. If 

the problem prevents the client from communicating with the server, the 

client can receive an error message. In this case, the user can try to 

complete the transaction at a later date. The other scenario is that the 

client successfully submits the request and the server completes the 

transaction, but is then unable to send the reply to the client. In this 

case, the client can become 'hung' while waiting for a response that 

will never arrive. 

Instead of using a synchronous process such as RPC to send a 

request directly to the server, messages can be placed and retrieved 

from a queue. An asynchronous message will not block the execution of 

an application when a reply or response is not required, improving 

overall performance. 

The differences between RPC and MOM are analogous to the 

differences between a telephone and an e-mail. A telephone is a direct 

point-to-point communication requiring both parties to be engaged. In 

contrast, an e-mail is sent to an 'inbox' (mail server) where it sits until 

one is ready to read and respond to it. 

Simplifies application communication 

MOM removes communication details from an application, simplifying 

application development. Messaging is often used to coordinate programs 

in dissimilar systems or written in different programming languages. 

The contents of a message can be anything from a simple text string to 

a serialized object or an XML document.


Scalability 

MOM is a highly scalable technology. The scalability of MOM has 

resulted in its wide-spread use in some of the world's largest and most 

complex systems, including many within demanding Wall Street financial 

institutions. 

Reliability 

MOM is not a new technology. It has been around for over a decade 

and has a proven track record in some of the most demanding 

environments. It is extremely reliable and able to handle high 

transactional systems. 

8.3.2. Types of communication 

There are three asynchronous: broadcasting, publish/subscribe and pointto-point 

and one synchronous: message passing messaging models in 

common use today. 

Broadcasting 

In a broadcast communication, a message is sent to every application on 

the network. Broadcasting may also be referred to as 'fire-and-forget'. 

Applications then decide if they want to act on the message. If an 

application has a need for the message, it will process the request and 

possibly respond to the sender. Otherwise, the message is ignored. 

Broadcasting is generally not recommended for a messaging solution, 

as it can impact network performance by increasing overall network 

traffic. 

Publish/subscribe 

A publish/subscribe messaging system supports an event-driven 

model where information consumers and producers participate in the 

transmission of messages. Producers 'publish' events, while consumers

Producer 

Topic 

t 


Subscribes 

Delivers 

Msgl 

Delivers 

Subscribes 

Figure 8.2. — Publish/subscribe messaging system 

Subscriber 1 

Subscriber 2 

'subscribe' to events of interest and consume events (see Figure 8.2). 

Producers associate messages with a specific topic and the messaging 

system routes messages to consumers based on topics the consumers 

register interest in. 

Publish/subscribe allows each application in the system to decide 

which events it wants to be notified about. Publishers do not know 

which applications are subscribing, nor do they care. The messaging 

middleware is responsible for ensuring that each subscriber receives the 

message once it receives it from the publisher. TIBCO's TIB/Rendezvous 

popularized the publish/subscribe model, where it found a large following 

in the financial industry. 

Point-to-point 

In point-to-point messaging systems, messages are routed to an individual 

consumer which maintains a queue of 'incoming' messages. Messaging 

applications send messages to a specified queue and clients retrieve 

messages from a queue. 

As Figure 8.3 illustrates, the traditional point-to-point MOM architecture 

can create a maintenance nightmare. Each application's messaging 

service must know about the messaging services of all other applications 

in order to communicate. As new applications are added to the enterprise, 

their messaging services must be systematically updated to communicate 

with each application.


Message passing 

Mini 

Computer 

Mainframe 

Unix 

! WinNT 

AS/400 

Figure 8.3. — Point-to-point messaging system 

Message passing uses a request/reply model where the communication 

occurs in a synchronous manner, requiring the calling application to 

halt execution until a response is received. Synchronous messaging 

requires that every application, server and service necessary to complete 

the communication must be available and in service, just as if it where 

an RPC communication. 

8.3.3. MOM frameworks 

There are two types of messaging frameworks: message queuing and 

message brokers. Traditional MOM supports the point-to-point model 

while message brokers support the new paradigm of a hub-and-spoke 

model. Message brokers offer much potential in B2Bi and may be the 

closest thing to EAI nirvana that the industry has seen. 

Message queuing 

Message queuing is a point-to-point model of communication between 

programs. Messages are stored in queues, which can either be buffered


or persistent. Each application 'node' contains its own message queue. 

Message queuing is often associated with IBM's popular MQSeries, 

which has been used for several years as the application integration 

solution of choice for the mainframe and UNIX platforms. 

Message brokers 

A better approach to point-to-point model of message queues is a 

message broker. A message broker is an intelligent intermediary that 

directs the flow of messages between applications, which become sources 

and consumers of information. Message brokers provide a very flexible 

communications backbone and such services as data transformation, 

message routing and message warehousing (see Figure 8.4). 

Message brokering is rapidly proving to be the most flexible and 

adaptable way to translate between multiple information formats found 

in typical enterprise application environments. Message brokers also 

provide additional services, such as data transformation, event-driven 

processing and intelligent routing. Message brokers are discussed in 

greater detail in the chapter on integration brokers. 

Legacy System 

(Mainframe) 

ERP System 

(SAP, Peoples eft, 

Baan) 

Adapter 

Adapter 


Broker 

Adapter 

Adapter 

CRM System 

(Clarify, Siebel) 

SCM System 

'"§. (i2, Manugistics) 

Figure 8.4. — Hub-and-spoke approach of message brokering


8.3.4. MOM middleware 

The most commonly used MOM middleware includes IBM's MQSeries, 

Microsoft's MQMQ and Sun's JMS. 

MQSeries 

IBM's MQSeries was introduced in 1992 and is available on over 40 

operating systems, including AIX, HP-UX VMS/VAX, Solaris, Linux, 

Windows 95/98/NT/2000 and MacOS. MQSeries is easily the dominant 

leader in the MOM market, providing the vast majority of MOM 

services for mainframe and legacy systems. According to the Gartner 

Group, MQSeries accounted for about three-quarters of the 2000 

worldwide revenue for all embedded message oriented middleware 

(MOM). 

MQSeries uses queue managers in a point-to-point model. Queue 

managers communicate across the network using channels, which run 

over a variety of transport protocols, including TCP/IP, NetBIOS, SNA, 

SPX and DECnet. Applications are written using a common programming 

interface, known as the message queue interface (MQI), so that 

applications developed on one platform can be transferred to another. 

Figure 8.5 shows how MQSeries passes messages to applications 

with separate queue managers on different machines. 

Queue 

Manager 

Queue 

T 1^. 

Program A 

(MQPUT) 

Message 

Channel 

Queue 

Manager 

Queue 

a 

Program B 

(MQGET) 

Figure 8.5. — MQSeries queue managers communicate using message channels


Program A makes an MQPUT call specifying not a local queue but 

a local definition of a remote queue. This definition identifies a queue 

on another queue manager. The queue manager to which Program A is 

connected puts the message on a special queue called a transmission 

queue. The message is then automatically sent along the channel 

connecting the two queue managers. The receiving queue manager puts 

the message on the queue that was originally specified by Program A. 

This message is stored on the queue until it is retrieved by Program B, 

after Program B has issued an MQGET call. 

MQSeries can support three kinds of transactional operations as 

follows: 

• Internal Transactions — MQSeries supports internal operations and 

transactions related to the actual messages. Messages are managed 

using transactional controls, allowing it to commit or rollback/resubmit 

messages in the event of a failure. In that case, all messages would 

rollback and the original input message would be reinstated on the 

queue. 

• External Transactions — MQSeries supports external transactional 

managers, such as TP monitors. MQSeries can commit or rollback all 

message processing, based upon the success or failure of the external 

transaction. In the event of a failure, all messages would rollback and 

the original message would be reinstated on the queue. In this mode, 

MQSeries is acting as a so-called resource manager. MQSeries can 

integrate with any X/Open XA compliant transaction manager, such 

as BEA Tuxedo and IBM's CICS. 

• Self Transactional — MQSeries can act as a transaction manager, 

managing messaging and other X/Open XA-compliant resources, such 

as databases. This allows MQSeries to support transactions without 

the use of a TP monitor or application server. MQSeries does not 

provide all the capabilities of an enterprise TP monitor, but it can be 

a good fit where a need for transaction management is at a minimum. 

MQSeries provides intelligent routing, allowing servers to forward 

messages along the shortest path available. Intelligent routing will 

also route messages around networks which have failed or which are 

experiencing problems.


MQSeries is supported by most of the leaders in message brokering 

tools (besides its own MQSeries Integrator). With its dominance in the 

MOM marketplace, MQSeries will be a component of most middleware 

solutions. 

Microsoft message queue (MSMQ) 

Microsoft introduced MSMQ in 1998 as an add-on to Windows NT, 

and has become a base service in Windows 2000. MSMQ, along with 

Microsoft transaction server (MTS), was Microsoft's first attempt to 

penetrate the enterprise computing market. This attempt has culminated 

in the recent release of their .NET architecture, which has the potential 

to thrust Microsoft into a leadership role in the enterprise computing 

market. Though slow to be adapted, there is definitely interest in 

MSMQ, if for any reason, due to the Microsoft name. 

As with most Microsoft services, MSMQ is implemented using a 

series of ActiveX components and DLLs, which provide an API for 

accessing its capabilities. MSMQ is Microsoft centric and will only 

work within a Microsoft environment. However, gateways such as 

Microsoft's host integration server (formerly SNA server) do exist to 

allow MSMQ to communicate with other MOM products and other 

platforms. 

MSMQ uses queue managers in a point-to-point model. There are 

four types of queues within MSMQ: outgoing, system, public and 

private. Messages reside on queues between the time they are written 

by one application and the time they are read by another. Queues use a 

combination of memory and disk to provide storage consistent with 

particular kinds of message. 

MSMQ structures its resources around enterprises and sites. 

Information about an enterprise and sites is hosted in the message 

queue information store (MQIS) which is a database or distributed 

directory that MSMQ uses to store information describing the network. 

At the enterprise level, a primary enterprise controller (PEC) would 

exist on a machine to define the information about an enterprise. Within 

an enterprise, MSMQ would have sites containing a primary site 

controller (PSC) and a backup site controller (BSC), which usually 

correlates to one physical location.


The MQIS provides intelligent routing and supports transactional 

management, similar to MQSeries, though this is usually accomplished 

with the assistance of MTS. MSMQ also provides some of the following 

features: 

• Prioritization — Messages are sorted by priority within the queue. 

Messages with high priority are processed before messages with low 

priority. 

• Encryption — Messages may be declared as public or private. Private 

messages will be encrypted by MSMQ and decrypted upon receipt by 

the receiver. 

• Component Streaming — MSMQ allows COM/COM+ components 

to be serialized into a message and reconstituted on the receiving 

end. 

Java message service (JMS) 

The Java message service (JMS) is a recent addition to the J2EE and 

EJB specification. J2EE (discussed in the section on Distributed Objects) 

is a quickly evolving distributed object standard developed by Sun 

Microsystems. Realizing the importance of messaging in distributed 

systems, Sun has developed the JMS API, allowing Java applications to 

send and receive messages. 

JMS is not a traditional stand-alone MOM solution like MQSeries, 

but rather a J2EE-specific messaging solution. The JMS API adds to a 

common J2EE API and provider framework that enables the development 

of portable, message-based applications in the Java programming 

language. 

JMS provides a common interface to standard messaging protocols 

and to special messaging services in support of Java programs. JMS 

supports point-to-point and publish-and-subscribe models. 

A JMS application is composed of the following parts (see Figure 8.6): 

• JMS provider is a messaging system that implements the JMS 

interfaces and provides administrative and control features. 

• JMS clients are Java applications that send and receive messages. 

• JMS messages are standard messages consisting of a header and 

body.


V. 

Message 

Prod ucer Creates 

I Sends to 

f Connection "\ 

\ Factory ) 

• Creates 

Connection I 

1 Creates 

Session 

• Creates 

Message 

^^^^< Message 

Qeates Consumer 

Figure 8.6. — JMS building blocks 

I Receives From 

Destination } 

• Administered objects are pre-configured JMS administered objects used 

by clients. There are two kinds of administered objects, destinations 

and connection factories. 

• JMS domains allow classification of the messaging environment as 

either point-to-point or request/reply. The domains are implemented 

using the JMS API. One or both domains can be supported in a 

single application. 

Non-JMS clients are programs that use a messaging product's native 

client API instead of the JMS API. If the application predated the 

availability of the JMS API, it is likely to include both JMS and non- 

JMS clients. 

JMS promises to work in concert with other MOM products to 

provide reliable, asynchronous communication among components in 

a distributed computing environment. Using the JMS interface, an 

application can invoke the messaging services of IBM's MQSeries, 

Progress Software's SonicMQ and other popular messaging product 

vendors. Similar to MSMQ, JMS supports messages that contain 

serialized Java objects, as well as messages that contain extensible 

markup language (XML) pages.

8.4. Distributed Objects and Components 


The advent of object-oriented technology was difficult to miss. Almost 

every software designer or developer who has been involved with 

application programming over the past several years has read about or 

experienced object technology. Distributed object technology has 

promised to radically alter the way systems are developed and deployed 

by: 

• Defining a standardized approach to application development; 

• Enabling rapid application development by providing flexible, 

customizable, prefabricated, reusable components; 

• Enabling inter-application communication and integration across an 

enterprise; 

• Providing interchangeable 'plug-and-play' components; and 

• Combining other EAI technologies, such as transaction management, 

messaging and API's, into one architectural framework. 

Distributed object and component technology allow objects and 

components, distributed throughout servers within an enterprise, to 

inter-operate and share functionality. Client objects and components 

invoke public methods of server objects and components providing 

business method level integration. 

What is an object? An object is a self-contained software entity that 

usually models a real-world object. Objects consist of three distinct 

parts: 

• Private Data — information or attributes, generally of a persistent 

nature, which define an object; 

• Private Methods — internal procedures for accessing or updating the 

private data; and 

• Public Interface — public methods for communicating with other 

objects. 

An object contains both data and business logic in a single software 

entity or package. It is designed to carry out the same functions as those 

in the real world. Objects are assigned roles and responsibilities and 

contain all information they need to carry out their actions.


As an example, an employee system maintained by the HR department 

would track all aspects of an employee. There could be an Employee 

object which represents an actual employee. The Employee object could 

contain the following private data (attributes): 

• Name 

• Social Security No. 

• Start Date 

• End Date 

• Level 

• Salary 

These attributes would be persisted in a database. The Employee 

object would also have a set of private methods for manipulating or 

validating the private data. These methods usually contain logic internal 

to the object: 

• validateSSNO 

• checkSalaryRangeO 

Finally, the object has a set of public methods used for accessing the 

private data. These methods usually consist of a series of get and set 

functions: 

• getNameO 

• setName() 

• getS alary () 

• setSalary() 

Distributed object technology is very well suited for heterogeneous 

systems and architectures which exist in most organizations. Distributed 

objects encapsulate the business logic and data within objects, allowing 

them to be located anywhere within a distributed system. Objects can be 

linked together in a plug-and-play manner to interoperate across networks. 

Distributed object technology allows valuable legacy systems to be 

'wrapped' and appear to the developer to be objects. Once wrapped, the 

legacy code can participate in a distributed object environment. Object 

wrapping allows businesses to leverage existing legacy code while 

migrating to a new enterprise architecture.


Distributed objects must work within a common framework, using a 

commonly distributed protocol. There are currently three competing 

distributed architectures in use today: 

• OMA's CORBA — Object Management Architecture, Common Object 

Request Broker Architecture (Object Management Group — OMG); 

• Windows DNA's COMH Component Object Model (Microsoft); 

and 

• J2EE's EJB — Java 2 Enterprise Edition, Enterprise JavaBeans (Sun 

Microsystems). 

Each protocol defines specifications for object interoperability, 

interfacing, communication and distribution. These protocols will be 

discussed in detail in the next section. 

Though the concept of distributed objects has been around for 

decades, they are a relatively new and immature EAI middleware 

solution and need much work to meet unfulfilled expectations. 

The good news is that distributed architectures are beginning to 

fulfill their potential at a much faster rate than they have in the past by 

building on past failures and experiences. Distributed object middleware 

solutions are moving away from the academic or idealistic approaches 

that object-oriented design methodologies originally espoused to a more 

practical, component approach that can handle the real-life rigorous 

demands of an enterprise. 

8.4.1. Distributed components 

The true benefits of distributed object technology are components. 

Object-oriented programming has long been considered the nirvana of 

application development. However, it has never fulfilled its potential 

due to a lack of standards which allow objects to communicate with 

one another across processes, machines and networks. Consequently, 

object-oriented programming has tended to be contained to just an 

application with no efficient means of inter-application communication. 

The solution to this problem is a system in which application 

developers create reusable software components. Components are autonomous, 

self-managing and packaged objects that can be placed anywhere 

on the network, implement a common set of business services and


provide the fundamental building blocks for creating distributed systems. 

They can be developed and deployed independently of other system 

components. Components are designed to be the ultimate plug-and-play 

application development solution. 

Components often go beyond basic object services by providing: 

• High level transaction management; 

• Security; 

• Event-handling; and 

• Persistence. 

Object technology has now been relegated to the development 

methodology used for implementing distributed component architecture. 

Components are created and deployed using a protocol, such as 

those specified for CORBA, COM or EJB (discussed in the next 

section). COM and EJB are both based on component architecture, 

while CORBA has recently addressed the need for components with its 

CORBA Component Model (CCM) protocol. 

8.4.2. Distributed object frameworks 

Distributed object frameworks have come a long way from the original 

object-oriented programming methodologies espoused by the academic 

community. These new frameworks extend well beyond objects, with 

each of these frameworks, including OMA, Windows DNA and J2EE, 

offering a wide range of services. Some elements common to all the 

frameworks include: 

• A distributed enterprise level framework or specification (OMA, 

J2EE, Windows DNA); 

• A distributed object or component framework or specification 

(CORBA, EJB, COM+); 

• An interface definition language (IDL); 

• Messaging and MOM; 

• Transactional processing and management; 

• Security; 

• Persistence; and 

• Event handling.


Each framework is a book in itself. Some aspects of these frameworks, 

such as MOM (MSMQ and JMS), have been previously touched upon 

in this chapter due to their ever-increasing importance in distributed 

systems. For the purpose of brevity, this section will focus on the 

distributed object/component element of each framework. 

8.4.3. OMA — CORBA 3 

The common object request broker architecture, or CORBA, was the 

first successful distributed architecture protocol to be developed. CORBA 

is a distributed object/component technology that is platform and 

language independent and allows remote object creation and remote 

object method invocation. 

OMA architecture 

CORBA is a protocol based on the object management architecture 

(OMA) developed by the OMG. The OMG is a consortium formed in 

1989 to define the standards and protocols required for distributed 

object systems in heterogeneous environments. OMG's objective is the 

definition of the OMA, which includes four sets of standards: the 

Common Object Request Broker Architecture (CORBA), Common Object 

Services Specification (COSS), Common Facilities and Application 

Objects. Unlike the COM and EJB protocols, the CORBA and OMA 

protocols are developed by a consortium which helps ensure that the 

final specification is product or technology independent. 

In 1992, OMG first approved the CORBA protocol that defined the 

services to be provided by an Object Request Broker (ORB). The ORB is 

at the heart of CORBA and ORB provides a mechanism for transparently 

communicating between client requests, target objects and other ORBs. 

The ORB simplifies distributed programming by decoupling the 

client from the details of the method invocations. This makes client's 

requests appear to be local procedure calls, when in fact the ORB is 

operating on a remote server (see Figure 8.7). When a client invokes an 

operation, the ORB is responsible for finding the object implementation, 

transparently activating it if necessary, delivering the request to the 

object and returning any response to the caller.


Client Machine Server Machine 

•" 

V) 

Client 

Application 

• 

User 

Code 

Function Call 

Stub 

Code 

Request 

ORB 

Code 

J 

HOP Message 

Server 

Application 

r \ 

User /CORB^X 

Code ' v v bje 5yf 

Function Call 

Skeleton 

Code * 

Function Call 

ORB 

Code 

v *y 

Figure 8.7. — Client application invoking a remote CORBA object function 

This decoupling takes place through the use of an Interface Definition 

Language (IDL). The IDL separates the object's interface from its 

implementation. The parameters that are used with the object interface 

and the named operations that the object can perform are described 

with the IDL. 

Most ORBs implement the CORBA Internet Inter-ORB Protocol 

(HOP), which runs over TCP/IP. This protocol is designed to provide 

efficient interoperability between ORB applications. 

The OMA architecture categorizes objects into four categories: 

1. CORBA Services; 

2. Horizontal CORBA Facilities; 

3. Domain (Vertical) CORBA Facilities; and 

4. Application Objects. 

CORBA services 

These are base services that are used by many distributed object 

programs. They provide the equivalent of system-level services to


applications and components. Some of the more popular CORBA 

Services include: 

• Naming Service — A directory service which allows clients to find 

objects based on names, similar to the white pages of a telephone 

book; 

• Trading Service — A directory service which allows clients to find 

objects based on their properties, similar to the yellow pages of a 

telephone book; 

• Event Service — Defines generic interfaces where supplier object 

can input events and consumer objects can receive them; 

• Notification Service — Adds event typing and filtering to the basic 

event service; and 

• Security Service — An interface for providing end-to-end security 

over open channels. 

There are also Object Service specifications for transactions, 

messaging and licensing, as well as many others. 

Horizontal CORBA facilities 

CORBA facilities sit between the CORBA services and application 

objects. CORBA facilities are application-level services that allow 

developers to build component-based objects. An example of such a 

facility is the Distributed Document Component Facility (DDCF), a 

compound document common facility based on OpenDoc. Examples of 

CORBA facilities include: 

• Internationalization service; 

• Secure time facility; 

• Print facility; and 

• Mobile agents facility. 

CORBA domains 

These interfaces fill roles similar to object services and common facilities 

but are oriented towards specific industries. For example, one of the 

first OMG RFPs issued for domain interfaces is for Product Data


Management (PDM) enablers for the manufacturing domain. Other 

OMG RFPs will soon be issued in the telecommunications, medical and 

financial domains. 

Application interfaces 

These are interfaces developed specifically for a given application. 

Because they are application-specific and because the OMG does not 

develop applications (only specifications), these interfaces are not 

standardized. However, if over time it appears that certain broadly 

useful services emerge out of a particular application domain, they 

might become candidates for future OMG standardization. 

CORBA 3 

The latest version of CORBA, CORBA 3, is built upon both the 

successes and shortcomings of earlier versions of CORBA. CORBA 3 

is divided into three major categories: 

• Java and Internet integration; 

• Quality of service control; and 

• CORBA Component Model (CCM). 

The biggest and most anticipated change in the CORBA 3 standard 

is the CORBA Component Model. The introduction of CCM, along 

with other features such as messaging, has helped CORBA catch up 

to the other component frameworks. A few of the new CORBA 3 

specifications, as provided by OMG, are outlined below: 

Java and internet integration 

CORBA 3 provides enhanced integration with the Java language and 

the Internet: 

Java-to-IDL Mapping 

This mapping allows Java RMI objects to interoperate over the network 

as CORBA objects. They have CORBA object references and emit the 

HOP protocol. New mapping defines IDL interfaces for Java objects


that lets them use the OMG's HOP protocol for remote invocations and 

allows Java servers to be invoked by CORBA clients written in any 

CORBA-supported programming language. 

Firewall Specification 

The CORBA 3 firewall specification will define the capabilities CORBA 

needs to safely traverse firewalls. 

Interoperable Naming Service 

The interoperable name service defines one URL-format object reference, 

corbaloc, that can be typed into a program to reach defined services at 

a remote location, including the naming service. A second URL format, 

corbaname, actually invokes the remote naming service using the name 

that the user appends to the URL and retrieves the IOR of the named 

object. 

Quality of service control 

The new messaging specification defines a number of asynchronous and 

time-independent invocation modes for CORBA and allows both static 

and dynamic invocations to use every mode. 

CORBA components package 

The three major parts of CORBA components are: 

• A container environment that packages transactionality, security and 

persistence and provides interface and event resolution; 

• Integration with EJBs; and 

• A software distribution format that enables a CORBA component 

software marketplace. 

8.4.4. Windows DNA — COM+ 

Windows DNA has evolved from the middleware services originally 

provided in Windows NT, including the Component Object Model 

(COM), Distributed COM (DCOM), Microsoft Transaction Server (MTS) 

and Microsoft Message Queue (MSMQ). The foundation of Windows


DNA is COM+. COM+ has a long history originating from Microsoft's 

Object Linking and Embedding (OLE) framework creating COM and 

then evolving from COM (and MTS) to its current form. 

Windows DNA platform 

One big difference between the CORBA, J2EE and Windows DNA 

frameworks is that the elements of Windows DNA can be both protocol 

and product based. The major elements of DNA include: 

• Windows 2000 — Most Windows DNA services are now integrated 

with the Windows 2000 operating system. As mentioned earlier, 

Windows DNA is not platform independent. 

• Internet Information Services (IIS) — IIS is Microsoft's Web server 

and one of the leading Web servers in use on the Web. It is now part 

of the Windows 2000 operating system. 

• COMH COM+ is the component architecture for Windows. COM+ 

is a marriage of COM and Microsoft Transaction Server (MTS). The 

COM+ framework is discussed in detail in this section. 

• Microsoft Message Queue (MSMQ) — MSMQ provides asynchronous 

messaging in the DNA environment. 

• Universal Data Access (UDA) — UDA is Microsoft's latest data 

access strategy that encompasses OLE DB and ActiveX Data Objects 

(ADO) for accessing databases and datastores, Active Directory 

Services Interfaces (ADSI) for accessing the directory services of 

Windows's 2000 Active Directory and Collaborative Data Objects 

(CDO) for accessing Microsoft Exchange. 

Microsoft's new .NET initiative extends Windows DNA even further 

by incorporating additional integration and Web services, including: 

• Host Integration Server — Provides gateways to allow bi-directional 

access to legacy systems, including mainframe, OS/390, OS/400 and 

Unix systems from a Windows platform. 

• BizTalk Server 2000 — BizTalk Server uses a message passing model 

to integrate applications. It is oriented toward XML as a data format, 

but can also handle other formats such as HTTP URLs and MSMQ 

messages.


• Internet Security and Acceleration Server 2000 (ISA) — Contains 

two apparently unrelated applications. The first product, Internet 

security, is a firewall for setting access policies and network authentication. 

The second product, Acceleration server, is a content caching 

server. 

• Application Center Server 2000 — Provides an administration tool 

for managing clusters of COM+ servers, a feature which was 

noticeably lacking in DNA. 

Microsoft has struggled to penetrate the enterprise distributed 

component market, though their latest initiatives, including .NET, could 

make them competitive in this space. The fact that they are Microsoft 

doesn't hurt either. Though it may take Microsoft some time to capture 

a market, they are usually successful at simplifying and demystifying 

technologies to the point where they become an out-of-the-box 

commodity (usually accomplished by integrating the technology with 

the operating system). 

COM+ 

COM and COM+ are the distributed component pieces of the Windows 

DNA platform for building distributed application in a Microsoft 

Windows environment. Much like CORBA, COM provides a framework 

and standards for object and component communication (see Figure 8.8). 

Client Application 

T 

diem Communicates 

directly to Object 

COM+ 

Establishes Connection 

| Object 

Server Application 

Figure 8.8. — Basic COM communication process


COM components can be written in any language, though Microsoft 

makes it easier to create COM components using Microsoft development 

languages, such as Visual Basic and Visual C++. 

COM provides two types of servers to allow clients to invoke a 

component: in-process and out-of-process. These COM servers provide 

much of the same roles as an ORB. 

In-process Server — An in-process server is a component where the 

objects run inside the client's memory space. Essentially, the client has 

a copy of the component on the local machine. In-process servers are 

implemented using DLLs or EXEs. The components are invoked using 

a local procedure call (LPC) (see Figure 8.9). LPCs are a means of 

communication between different processes on the same machine. As 

might be expected, in-process server components experience little 

overhead and are very quick to execute. 

Out-of-process Server — An out-of-process server runs in a separate 

process or memory space, usually on a separate machine (see Figure 8.10). 

They serve up 'remote' objects which are usually independent applications 

in their own right. Out-of-process servers use RPC-like communication 

similar to HOP with CORBA and RMI with J2EE. The 

benefits of out-of-process servers include component reusability and 

Client 

Application 

Vv_ 

Client 

Application 

DCE 

RPC 

Client Process 

-1 r 

Figure 8.9. — In-process server call 

_i 

CCM 

) 

! 

y 

HI \ 

^ ( 

RPC 

-Vi 

Remote Machine 

Remote Server Process' 

COM 

Stub 

Figure 8.10. — Out-of-process server call 

Pemote Server 

Remote 

Object 

vk


maintainability. The drawbacks include slower performance due, to the 

communication overhead incurred from RPC calls and brokering 

performed by COM, such as marshalling. 

COM+ was born from the marriage of traditional COM and MTS. 

COM+ supports transactions natively — components are inherently 

designated a transaction. In COM+ there is no longer a need to deploy 

a component and then specify its transactional requirements. Instead, 

the transactional semantics are part of a component as defined by the 

programmer, thereby reducing administrative error. 

COM+ also provides transaction processing monitoring capabilities 

by allowing multiple COM objects to be stringed together into a single 

transaction. If an error occurs in any component, COM+ will roll back 

all of the work and restore the system to its original state. 

DCOM is what puts the 'distributed' in COM. DCOM is an extension 

of Microsoft's Component Object Model (COM) across the network. It 

allows a transparent implementation of COM between two or more 

computers. DCOM is now built into the Windows 2000 operating 

system which has reduced the effort to deploy a distributed COM 

system. 

Fundamentally, DCOM specifies a network protocol for making this 

transparency work. When a client and component reside on the same 

computer they communicate via local procedure calls. When a client 

and a component reside on different computers, DCOM inserts itself 

into the mix by using remote procedure calls to access the components 

across the network (see Figure 8.11). 

DCOM 

Protocol 

LPC 

DCE 

RPC 

Figure 8.11. — Client-server communication via DCOM protocol 

CCM 

Remote 

Component


To the client and component, the distributed calls are totally 

transparent. The client never has to change how it calls the component. 

To the component it does not even know that its client is on another 

machine. 

COM and DCOM use a binary specification to provide language 

neutrality. A COM/DCOM component can be created with Java, C++, 

MS Visual Basic, Delphi, PowerBuilder, etc. This is one of the advantages 

COM+ provides over J2EE which is locked into Java. DCOM 

allows the organization or developer to choose a language which he/she 

is most familiar with. 

8.4.5. J2EE — EJB 

Sun Microsystems released the Java platform in 1995 and touted it as a 

way to create applications that would run on any computer, regardless 

of the operating system and deployment environment. The battle cry for 

Java was 'write once, run anywhere'. 

Building upon the success of the Java language, Sun leveraged the 

capabilities of Java with an eye on the enterprise framework of CORBA 

to develop a new enterprise Java model. 

J2EE platform 

The J2EE platform is the current version of enterprise Java. There are 

actually three editions of the Java 2 platform: the Java 2 Platform, 

Micro Edition (J2ME) for small devices and smartcards; the Java 2 

Platform, Standard Edition (J2SE) for desktops; and the Java 2 Platforms, 

Enterprise Edition (J2EE) for creating server-based applications and 

services. It is the J2EE platform which provides an enterprise framework 

for distributed components. J2EE is a set of coordinated specifications 

and practices which enable solutions for developing, deploying and 

managing multi-tier server-centric applications. 

The primary technologies in J2EE include (see Figure 8.12): 

• Enterprise JavaBeans (EJB); 

• Java Server Pages (JSP);


Messaging Services Communication 

innllnMAK JavaMail JDBC TCP/IP. HTTP. SSL 

Application JMS JMDI pMI 

Services 

1 Business 

Logic 

I 

JTA FMI-IICP 

WLEC 

Entity Session 

Beans Beans 

EIR AwitafaMr 

Presentation JavaSeivei Sei.,,_,.. HTML' 

Pages XML 

Logic 

W*» Contrtwar 

Figure 8.12. — J2EE platform 

• Java Servlets; 

• Java Naming and Directory Interface (JNDI); 

• Java Transaction API (JTA); 

• Java Interface Language (IDL) for CORBA; 

• JDBC Data Access API; and 

• JavaMail. 

Though J2EE is a platform independent protocol, the underlying 

technology is Java, a language which is owned and maintained by Sun. 

Application server vendors pay a royalty to Sun to implement J2EE 

technology. 

EJB 

EJB has become a widely adopted server-side component architecture, 

based on the J2EE framework. The EJB specification is an industry 

initiative led and driven by Sun with participation from many vendors 

in the industry. Sun owns the interactive and iterative process of 

defining, creating and publishing the specification while ensuring ongoing


Security 

Distributed Object 

Management 

Enterprise 

JavaBeans 

Persistence 

Transactions 

Figure 8.13. — Few features of enterprise JavaBeans 

incorporation of input and feedback from the industry and the general 

public. 

EJB technology is the core of J2EE. It enables developers to write 

reusable portable server-side business logic for the J2EE platform. 

Some of the key features of EJB include the following (see Figure 8.13): 

• EJB components are server-side components written entirely in the 

Java programming language; 

• EJB components contain business logic only — no system-level 

programming; 

• System-level services such as transactions, security, life-cycle, 

threading, persistence, etc. are automatically managed for the EJB 

component by the EJB server or container; 

• EJB architecture is inherently transactional, distributed, portable, multitier, 

scalable and secure; 

• Components are declaratively customized (can customize: transactional 

behavior, security features, life-cycle, state management, persistence, 

etc.); and 

• EJB components are fully portable across any EJB server and any 

OS.


EJB technology has gained wide spread industry adoption and support. 

The EJB specification is unique from CORBA and COM+ in that the 

specification was developed using industry-wide collaboration, as with 

CORBA, yet the specification is controlled by a single company, as 

with COM+. This has given EJB the advantage of obtaining industry 

acceptance from the application server vendors, while at the same time, 

the ability to advance and modify the specification quickly, since 

ultimately there is really only one owner and final decision-maker. 

At a high level, EJBs do not differ much from CORBA, or even 

COM+. EJBs require an IDL to separate the interface from implementation; 

it supports transaction management, component level security and 

messaging; and it is object-oriented based. 

EJB differs from its brethren, as follows: 

• EJB is a Java-based protocol. Though EJBs can interface with non- 

Java components through wrappers or interfaces to CORBA, EJBs 

are Java at heart. 

• In addition to being platform independent, EJBs are also middleware 

independent. An EJB application can, in theory, be ported from one 

application server to another with minimal rework. 

• EJBs live in a container. The container provides several services for 

the EJBs, including lifecycle management and instance pooling and 

transaction management. The container intercedes between client 

calls on the remote interface and the corresponding methods in a 

bean to enforce transaction and security constraints. The container 

also enforces policies and restrictions on bean instances, such as 

reentrance rules and security policies. 

• EJBs were designed to wrap around, or encapsulate, existing legacy 

systems, applications and datastores, allowing an organization to 

leverage its existing infrastructure. These existing systems will appear 

as a standard bean within the container. EJB can also co-exist with 

other technologies, including COM/DCOM, ActiveX and CORBA. 

Types of beans 

The 'bean' part of Java Beans is Sun's name for a Java component. 

There are two types of enterprise beans: session beans and entity beans.


Session beans 

Session beans represent behaviors associated with client sessions. A 

session bean instance is typically private to a particular client connection. 

It is usually not shared among multiple clients and therefore becomes a 

logical extension of the client application. Interfaces are defined to 

support a session bean accessing and modifying data as part of a 

transaction. 

SESSION BEAN PROPERTIES 

• Transaction capable; 

• Handles one transaction at a time; 

• Accesses and updates database for the client; 

• A logical extension of the client; 

• Used only by client who creates it; 

• Short lived — lives only as long as the client; 

• Does not survive crash of client or server; 

• Hides its identity (appears anonymous); 

• No finder method; and 

• Fields represent the state of the transient conversation with the 

client. 

Stateless versus stateful session beans 

Session beans can be either stateful or stateless. A stateless session 

bean does not maintain an internal state and has no persistence. The 

state of the bean will always be the same both before and after any 

method calls or transactions have occurred. Since session beans of the 

same type are identical, they can be pooled to service multiple clients. 

They can also be created and destroyed easily by the container, since 

they hold no state. 

A stateful session bean, on the other hand, maintains an internal 

state that can be accessed and modified directly by the client. A stateful 

bean can be accessed by only one EJB client and becomes a logical


extension of the client application. Since these beans can be persisted, 

they are often referred to as Persistent Session Beans. 

Entity beans 

An entity bean is persistent once it is created, until it is explicitly 

deleted. Entity beans represent specific persistent data, which is 

maintained in a database and the methods for acting on that data. Entity 

beans typically correspond to a database table row with a single row 

representing a single bean instance. The primary key for that row will 

provide the identification for that bean. Interaction with the database 

can be through the EJB container (container-managed) or handled directly 

by the bean through embedded SQL (bean-managed). 

• 

• 

• 

• 

• 

• 

• 

• 

ENTITY BEANS PROPERTIES 

Persistent; 

Handles multiple clients; 

Transactional; 

Survives server crash; 

Represents data in a database, along 

that data; 

Exposes its identity as primary key; 

Has finder method; and 

In a relational database context , there 

a table. 

8.4.6. J2EE application servers 

with the methods to 

act 

on 

is one bean for each row in 

In the following section, we will discuss two of the most popular J2EE 

compliant application servers. 

IBM WebSphere 

WebSphere is actually a series of products offered by IBM. The 

cornerstone of the WebSphere product suite is the WebSphere Application


Access Services 

[ (HTTP, HOP, RMI / HOP) ) 

Dynamic content services 

(JavaSeiver Pages, HTM_ or 

XML SSL) 

/ 

Ru nti me Se rvices 

Component Broker, Distributed ' 

CICS and Encina 

f" ^ ' 

Connection Services 

CCRBA Java, EJa 

Transactional fiPls 

PCS Browsers 

..J.. 

i 

i Web Server Java Servlet 

:EJB,CORBA 

>...__.__—*. Business 

Applications 

Relational 

Databases 

IBM DB2 

Oracle, Sybase. 

Informix.. JDBC 

Transactional 

Systems 

ERP 

Systems 

Figure 8.14. — IBM's WebSphere suite 

Pervasive devices 

(such as cell phones and 

handheld devices) 

I I 

Other 

Application 

Servers 

MQSerie & 

Lotus Domino 

Others 

(LDAP directories, 

ORBs, Oustnm 

applications) 

Server which is a Java 2 Enterprise Edition (J2EE)-compliant platform 

for developing, deploying and maintaining Web-based applications. The 

WebSphere suite comes with an impressive arsenal of products in 

support of the application server, including development tools monitoring 

components and configuration management utilities (see Figure 8.14). 

Some of the other products in the WebSphere family include: 

• WebSphere Studio; 

• WebSphere Personalization Server; 

• WebSphere Business Integrator; 

• WebSphere Portal Server; 

• WebSphere Host Integration Solution; 

• WebSphere Voice Server; 

• WebSphere Site Analyzer; and 

• DB2. 

The enterprise edition of WebSphere also comes bundled with other 

IBM products, including: 

• Component Broker — a complete, CORBA 2.0 compliant object 

transaction monitor; 

• Encina — a transaction processing (TP) monitor;

• CICS — another TP monitor; and 

• MQSeries — IBM's popular messaging product. 


Each of these products is an independent commercial product in 

itself. As might be expected, WebSphere also integrates with many 

other popular IBM products, including MQSeries Integrator and Lotus 

Domino. WebSphere is available on all the major operating systems, 

including AIX, Windows NT/2000, Solaris, Linux, IBM OS/390 and 

HP-UX. WebSphere comes with DB2 as the default database but also 

supports Oracle 8i and Sybase Adaptive Server, with some effort. 

Though the breadth of the WebSphere family seems impressive (and 

it is), the actual integration of all these tools is not always a turnkey 

operation. In a rush to provide the most comprehensive e-commerce 

product line, many of these products were placed under the WebSphere 

'umbrella' before full interoperability was attained. The WebSphere 

application server itself has had a reputation of being difficult to install 

and maintain. But IBM has deep pockets and a strong commitment to 

WebSphere, so each new release has provided tighter integration and 

better interoperability among the various products. And, of course, 

IBM's Global Services will be more than happy to help companies out 

with their integration problems. 

WebSphere is also the first software platform to incorporate the 

following elements to enable Web services, including: 

• SOAP (Simple Object Access Protocol) for Java server and tools for 

standard-format Web services data and communications; 

• UDDI (Universal Description, Discovery and Integration) for Java, 

providing a set of Java APIs for interacting with UDDI registries for 

Web services; 

• XML (Extensible Markup Language) upgraded XML parser for better 

performance and B2B communications; and 

• WSDL (Web Services Description Language), a common language to 

describe the capabilities of Web services. 

IBM has beaten other application server vendors to the punch by 

providing support for Web services within WebSphere. These new 

services will help WebSphere extend the enterprise to the Web, providing 

an end-to-end (or EAI to B2Bi) integration model.


Client 

Wirele 

BEA WebLogic 

Partner 

Offerings 

Campaign Manage: 

Commerce Server 

Personalisation Server 

Legacy 

Applications 

Mamfiames 

and Databases 

eLink 

Partner 

Offenngs 

Weblogic Integration 

WebLogic and Tuxedo Application Servers 

BEA Services 

Figure 8.15. — BEA family of WebLogic servers 

M 

Partners 

Suppliers 

Emplcyees 

r~,— 

Customers 

Like WebSphere, BEA's WebLogic is actually a family of products. BEA 

WebLogic Server, a J2EE-based application server, is at the heart of the 

WebLogic platform. The BEA family of WebLogic servers includes (see 

Figure 8.15): 

• BEA WebLogic Server; 

BEA WebLogic Express; 

BEA WebLogic Commerce Server; 

BEA WebLogic Personalization Server; 

BEA WebLogic Integration; and 

BEA Tuxedo. 

A high performance Web server is bundled in with WebLogic. 

WebLogic also integrates with BEA's eLink family of off-the-shelf 

enterprise application integration (EAI) products. eLink leverages the 

WebLogic platform to integrate existing legacy applications with 

e-commerce and B2B platforms. 

WebLogic is available on all the major operating systems, including 

AIX, Windows NT/2000, Solaris, Linux, IBM OS/390 and HP-UX.


Unlike WebSphere, WebLogic products are generally easier to install 

and maintain. In addition, integration and interoperability among various 

servers is tighter and simpler to implement than its main rival, 

WebSphere. WebLogic is one of the most mature and stable J2EE 

application servers available. 

BEA WebLogic has what IBM wants: market share. BEA was the 

first vendor to achieve widespread industry acceptance of a J2EE 

distributed component middleware platform. Though both IBM and 

BEA regularly make contradicting claims about their market share, it is 

IBM who must play catch-up (and it seems they are). 


Middleware technologies reduce the effort required to develop and 

maintain computer systems. By removing the complexities of 

heterogeneous environments inherent in most organizations, middleware 

products provide a reliable, scalable means for system integration within 

the organization. 

Middleware technologies advance the goals of B2Bi and enterprise 

application integration. By integrating disparate systems throughout the 

organization, middleware technologies can promote a zero-latency enterprise 

strategy, where data is exchanged across systems in real-time; reduce 

application development time and improve speed to market; create 

standardized development methodologies throughout an organization; 

facilitate the integration of systems inherited through mergers or 

acquisitions; and reduce application maintenance. 

Ultimately, the question is not if middleware should be used, but 

how and to what extent.

Chapter Q 

Integration Brokers 


Integration brokers are the middleware for extranets that provide an 

end-to-end integration platform addressing the critical business 

components required to completely automate business processes across 

the extended enterprise. 

In this chapter, we will present the different architectures of message 

oriented integration brokers (message brokers), their components and 

salient features. You will also get an overview of the leading integration 

broker solutions along with relevant case studies. 

254

9.1. Introduction 

Integration Brokers 255 

Traditionally, companies have used relatively flat architectures, such 

as file transfers, APIs and RPCs to integrate internal and external 

applications. These architectures utilize application specific adapters 

and messaging middleware. 

However, flat architectures are not suitable for B2Bi, which 

requires a more robust, scalable and systematic implementation. Such 

architectures, being quite rigid, lack the flexibility required in B2Bi. 

The physical architecture for B2Bi is multi-tiered, which introduces an 

integration broker between the applications (nodes) being integrated and 

shields the individual nodes or end points from each other and the 

actual integration services. Integration brokers, built primarily on 

messaging middleware, provide an end-to-end integration platform 

addressing the critical business components required to completely 

automate business processes across the extended enterprise. They provide 

wide-ranging, pre-built application adapters and bi-directional 

connectivity to multiple applications, including mainframe applications. 

Integration brokers enable data integration by allowing applications to 

exchange information at the program level (application oriented 

integration) or data level (data oriented integration). 

An integration broker extracts data from the source node at the right 

time, transforms the data, converts the schema and routes the data to 

the target node. Here, the node can be an application, a program, or a 

person — as defined in the business process workflow. Communication 

between applications and an integration broker occurs mostly in the 

form of messages. An integration broker also provides a repository for 

archiving, searching and retrieving these messages. 

Integration brokers do not replace traditional middleware as MOM, 

RPC and distributed TP monitors. They are in fact built on top of 

existing middleware technology, most often on messaging middleware. 

Therefore, in this chapter we will focus on integration brokers built on 

messaging middleware, also called message brokers. Message brokers 

are also known as middleware for extranets. 

A few leading vendors for integration brokers include — IBM 

MQSeries Integrator; Extricity; BEA eLink; webMethods B2B Enterprise; 

Mercator Enterprise Broker, WebBroker, CommerceBroker; NEON


eBusiness Integration Servers; SeeBeyond e*Exchange eBusiness 

Integration Suite; Tibco ActiveEnterprise, ActivePortal, ActiveExchange; 

Vitria BusinessWare; CrossWorlds Software; and Microsoft BizTalk 

Server. 

9.1.1. Integration brokers enable (best-of-breed) 

BOB approach 

A typical medium to large size company needs multiple applications 

that collectively support its entire business operation. No single software 

vendor can provide all these applications with elaborate functionalities 

for each industry. 

Integration brokers enable enterprises to select solutions from different 

software vendors that provide greater domain expertise and functional 

support. With their use, for example, a company can implement Clarify 

CRM, PeopleSoft Human Resources, Ariba e-Procurement, Oracle 

Financial, i2 SCM and SAP Utilities. 

9.2. Architecture of Integration Brokers 

Integration brokers are based on one of two distinct fundamental physical 

architectures: hub-and-spoke and message bus. Another derived 

architecture, known as multi-hub, connects several integration brokers, 

each of which is based on hub-and-spoke or message bus architecture. 

Let's have a closer look at these architectures: 

9.2.1. Hub-and-spoke architecture 

In hub-and-spoke architecture, there is a central server (hub) to which 

all internal and external applications (spokes) are connected (see 

Figure 9.1). The central server is actually the integration broker that 

provides all the integration services. The addition of any new application 

is extremely simple in this architecture, it simply needs to be plugged 

into the hub. From there onwards, it can communicate with any other 

application also connected with the hub. Administration of the integration

Legacy System 

(Mainframe) 

ERP System 

(SAP, PeopleScft, 

Baan) 

Adapter 

Adapter 


I A \ | lnteoration I/ 1 *\l , f C " S¥ste "\ 

g.\i s/~& Broker "S-^f—v - * 02, Manugistics) 

Broker ff » 

Adapter 

r V 

v 

Adapter 

CRM System 


Figure 9.1. — Hub-and-spoke architecture 

broker is fairly simple in this architecture, as everything is managed 

centrally. 

However, the centralized nature of this architecture is also its biggest 

drawback. If, for instance, connectivity to the integration broker is 

down due to network errors — the entire system would come to a 

standstill. No internal or external application is able to communicate 

with the other. To avoid such situations, this architecture requires a 

clustered solution in which multiple instances of integration brokers run 

on different physical machines. 

This architecture is suitable for small to medium size enterprises, 

which have relatively fewer internal and external applications to integrate 

with. 

The most widely used integration brokers based on this architecture 

are from webMethods, CrossWorlds and Vitria. 

9.2.2. Message bus architecture 

In message bus architecture, the message bus forms the backbone 

communication link to which all applications are connected (see


Metadata 

Repository 

ERP System 

(SAP, PeopleSoft, 

Baan) 

%\ / 

Adapter 

Adapter 

n 

Adapter 

Adapter 


Broker 

SCM System 

(i2, Manugistics) 

Adapter 

n Adapter 

Message 

Adapter 

tt 

Adapter- 

Databases 

(Oracle, Sybase) 

Figure 9.2. — Message bus architecture 

CRM System 


Adapter 

n Adapter 

Bus 

Adapter 

n Adapter 

Legacy System 

(Mainframe) 

Figure 9.2). Every message that flows between applications travels over 

the bus to the integration broker, which transforms, translates and 

routes the message to the receiving application. 

The addition of new applications is also simple in this architecture. 

The integration broker suite would provide either a pre-packaged adapter 

for the application or APIs to build an adapter for the same. After the 

new application is connected to the bus, it can communicate with all 

the applications that are connected to the bus. 

In this architecture, the integration broker should be viewed as 'just 

another service on the bus' and not as a hub. 

Since this architecture is distributed in nature, it offers better 

scalability and performance. It is more suitable for large size companies, 

which have a relatively large number of internal and external applications 

to connect with. 

The most widely used integration brokers based on this architecture 

are from Tibco and SeeBeyond. 

9.2.3. Multi-hub architecture 

A multi-hub architecture is characterized by the presence of multiple 

integration brokers, each one of which has many applications connected 

to it (see Figure 9.3). This configuration links together all the different

Application Application Application Application 

$ $ # $ 

Message 

Broker 

Message 

Broker 

£ ¥~^ 

Application Application Application 


Application Application 

$ $ 

Application^ H"*** I 

Broker | 

in? 

Message 

Broker 

Application Application 

Figure 9.3. — Multi-hub architecture 

integration brokers. The connectivity of the brokers is transparent to the 

underlying applications. Through their respective connection with an 

integration broker, they are integrated with all the other applications 

linked to different brokers in the system. 

This architecture is very useful as a scalability solution, where 

multiple instances of the same integration broker can be deployed on 

different physical machines. More such instances can be added if the 

number of applications to be integrated increases or the current solution 

is slow due to overload. 

9.3. Components of Integration Brokers 

The essential components of any integration broker include Messaging 

Manager and Message Warehouses, Application Adapters, Data 

Transformation Component, Workflow Manager, Metadata Repository 

and Administration Tool (see Figure 9.4). All of them work together in 

providing a robust, flexible and dynamic integration solution that supports 

the exchange and transformation of data from multiple applications over 

multiple networks. 

Several components such as the data transformation component and 

the workflow manager do not fall into the category of application or 

middleware. They can be placed in either applications or middleware.


Metadata Repository 1 

Administration Tool 

Workflow Manager 

Message 

Warehouses 

Components of 

Integration Broker 

Data Transform ation I 

Tool I 

Message Distribution! 

Manager 1 

Figure 9.4. — Components of an integration broker 

App 1 i c ati on Ad apters I 

From a systems architecture point-of-view, the ideal place for these 

components is within integration brokers, as it would provide a single 

point of integration. 

Here is an elaborated discussion of the components of an integration 

broker: 

9.3.1. Messaging services 

Messaging is defined as the process by which the source sends business 

events or data as strings of bytes to a destination, asynchronously or 

synchronously, over a communications pathway. 

At the core of an integration broker lies its ability to support 

mission-critical communications that include: 

• Capabilities for asynchronous and synchronous communication; 

• Message queuing; 

• Message flow control; 

• Publish-and-subscribe; 

• Filtering;


• Parsing; 

• Intelligent routing; 

• Extracting key identifiers and identifying specific processing rules; 

and 

• Guaranteed secured message delivery. 

The messaging services determine when and how the messages are 

routed, what to do with a message if the receiving application is not 

ready to receive it and several other features typical of a message 

broker. 

An integration broker can be built either on messaging middleware 

or provide adapters for message oriented middleware or message buses. 

In either case it has to enable guaranteed messaging of both the 

structure (syntax) and the meaning (semantics) of the data between 

applications. Many integration broker software vendors use MQ Series 

for message queuing. 

Message flow control is an important feature that an integration 

broker has to support for effective performance results. Assume a 

situation in which the source application is generating messages at a 

rate much faster than they can be received by the destination. In such 

a scenario, messages accumulate in the broker's memory, which may 

reduce the available CPU resources for other tasks. It should be able to 

throttle the source application, using flow control to avoid losing 

messages and slowing down the message throughput of the broker as 

a whole. Additionally, the broker should provide robust performance 

in the event of server overload and network congestion — all of 

which may result in a high number of unretrieved messages in the 

message queue. 

Each trading partner in a B2B application may have its own 

preferences in terms of transaction sets, message formats, communication 

transports, access privileges, routing and transformation rules and tracking 

and error-handling requirements. Integration brokers should support all 

these customizable preferences and enable message routing that directs 

data according to conditions set by the business. They should also 

enable message formatting so that applications can exchange information 

after adapting the presentation of the content to the requirements of the 

environment.


Integration brokers also have to provide an infrastructure and tools 

for storing the messages in message warehouses (saving a copy of 

all messages in a database or file, usually on disk and usually in an 

unprocessed format). Warehouses provide functionalities of auditing 

used for reporting, retrieving messages, associating messages with the 

generators and message non-repudiation. They provide a persistent buffer 

to store messages that could be lost in the event of the receiving 

application being unavailable. Messages can be retrieved and resent to 

the target application when it becomes available. 

9.3.2. Application adapters 

An application adapter provides a communication interface between the 

underlying application and the integration broker. It allows messages to 

be sent and received between the two, based on a business event or an 

explicit invocation. Some of the common methods used by adapters to 

enable communication include sequential file access, invocation of 

component methods using APIs, RPCs and direct database access. 

As discussed earlier, there is a different adapter for each application 

to be integrated (see Figures 9.5 and 9.6). The integration brokers 

should offer these adapters for the industry-leading enterprise applications 

and offer pre-packaged integration solutions for integrating pre-built 

applications with static code (such as SAP-i2, BroadVision-Siebel). 

Application adapters drastically reduce the deployment time of integration 

brokers, sometimes as high as 50%. 

An adapter should also be available to enable the communication 

between integration brokers and application servers supporting common 

object request brokers including CORBA, EJB, COM and COM+. 

Apart from providing adapters for core internal applications, 

integration brokers should also provide adapters that hook up with 

popular B2B trading exchanges, such as the Ariba Commerce Services 

Network. 

Integration brokers should include adapter development environment 

and toolkit for graphically generating custom interface components. 

The toolkit should also include APIs that make services of brokers 

available.

Legacy 

Systems 

CRM 

System 

SCM 

System 

VTT7 


Broker 

1 

Adapter for 

SAP R/3 

ALE 

BAPI / RFC 

ABAP Direct 

• RFC |RFC I : 

^ ir # 

SAP R/3 | 

System I 

Internal 

Applications 

Figure 9.5. — Adapter for ERP system-SAP R/3 

Legacy 

Systems 

CRM ERP 

\M7 

System System 


Broker 

T 

Adapter for 

i 2 System 

Common Data || Copy Maps 

Models. 

12 System 

ADW 

^- 

RhythmLink 

1 

\2 Engines 

Internal 

Applications 

Figure 9.6. — Adapter for SCM system-i2 

Integration Brokers 263


XML 

Document 

XML DTD 

or Schema 

Lj-$* *? S -! H **K i J® 

Adapter for 

XML 

Processed 

XML 

Message 

• *> ,v Integration 

Broker 

Transformed 

XML 

Message 

• iv ••*,&-,*, Application A 

* _>uj j*^.*, Application B 

Data 

*K , 

Transformation .j 

Tool r 

H Tr ansf 01 med • 

XML 

Message 

Figure 9.7. — Data transformation component 

9.3.3. Data transformation component 

Integration brokers should support an any-to-any document translation 

paradigm. The data transformation component of an integration broker 

performs the dynamic process of schema conversion and data transformation 

of messages as they are exchanged between the source and 

target applications (see Figure 9.7). It does so by deconstructing the 

message from the source application, interpreting the meaning of data 

using the metadata repository and mapping that data to the schema of 

the target application and reconstructing the message. It changes the 

original message structure and format based on the schema of each of 

the target applications. 

Without schema conversion and data transformation, no two disparate 

applications can communicate with each other. It is the responsibility of 

the integration broker to take the data from one application and transform 

it in such a way that the receiving application can understand it, i.e., all 

incoming messages have to be translated and mapped in the form of 

outgoing messages for the receiving application. 

As an example, consider the kind of data that can be exchanged for 

a new user creation between CRM application and ERP application 

with the WebLogic integration broker. When a new customer is created 

in a CRM system such as Clarify, an event in BEA WebLogic Integration 

is triggered, which initiates a business process that enters new customer 

data into SAP R/3 and sends a welcome e-mail.


Table 9.1. Semantic differences between source and target applications 

Source Application (CRM — Clarify) 

UserlD — Char (10) 

UserName — Char (50) 

PostalAddress — Char (100) 

PhoneNumber — Char (15) 

Target Application (ERP — SAP) 

user_id — Char (12) 

first_name — Char (20) 

middle_name — Char (2) 

last_name — Char (20) 

street_address — Char (20) 

city — Char (20) 

state — Char (5) 

zip — Char (7) 

country_code — Num (4) 

city_code — Num (3) 

phone_number — Num (10) 

Table 9.1 shows the semantic difference between the schemas of the 

two applications. 

It is apparent that the two applications have different data schemas. 

There will be several errors if an attempt is made to move the data from 

one to the other without transformation. However, if the same data is 

passed through an integration broker, it will transform the data from 

CRM application to a form that is in congruence with the schema of 

ERP application. 

Integration brokers should support a full range of data types, including 

all the leading standards such as XML, cXML, EDI, RosettaNet, 

EDIFACT, XI2, HL7 and SWIFT. 

Usually, integration brokers include a graphical tool known as 

DataMapper, which allows visual creation of maps that define the 

correspondence between the records and fields of the source application 

with those of the receiving application. A map may represent 

specifications in any language such as Extensible Stylesheet Language 

(XSL) style sheets that are used by the broker to perform the 

transformation described in the map.


9.3.4. Workflow manager 

Integration brokers work on the definition and management of the flow 

of messages that represent business processes between integrated 

applications. Thus, it is imperative for them to have a sophisticated 

workflow manager, which would allow users to visually create workflows 

representing inter-company business processes in the form of a sequence 

of events, routes, tasks and users. The execution environment should 

support event triggers, rules-based processing, threaded conversations, 

automatic event notification, timing control, triggers, exception 

management and alternative and parallel routing of documents. 

Advanced rules-based processing in an integration broker reduces 

the messaging overhead with content-based message recognition and 

routing. Rules support the creation and dispatch of multiple messages to 

multiple destinations from a single input message, while allowing 

different formats for each. The rules can be updated immediately, over 

time or on a delayed time frame. This sort of flexibility provides 

business users with effective control over business processes in a fast 

changing B2B environment. 

As a typical B2B example, an incoming purchase order may require 

cross-reference checking with ERP system for valid component 

identification number, financial system for verification of credit and 

several other necessary steps to complete the integration into business 

applications. These rules and the associated flow logic should be easily 

created within the broker-provided graphical user interface and shared 

between maps, reducing development time significantly. 

9.3.5. Metadata repository 

Metadata repositories store the definitions, formats, data elements and 

flow of messages that are used to exchange data between companies. 

Integration brokers can use these defined formats to parse and process 

messages. 

9.3.6. Administration tool 

An integration broker should provide a graphical, user-friendly 

administration tool that supports wide-ranging administrative functions,


including trading partner management, ability to monitor and properly 

control the state of operation of all events and indicate when they are 

completed, specifying security features, communication protocols and 

activity report generation. This tool will be used to target and troubleshoot 

problems. 

9.4. Services of Integration Brokers 

Integration brokers provide the following essential services (see 

Figure 9.8): 

9.4.1. Enable all types of integration 

The first and foremost feature of any integration broker is to enable all 

types of integration needs within an organization and in an extended 

organization through translating, routing and tracking of all types of 

Enables Publishing/ 

Subscribing of 

Web Services 

Based on Oper 

Architecture 

Easy to 

Administer 


Management: Workflows, 

Business Processes 

Integration Broker 

Platform Services 

Trading Partner 

'•'anagement 

Standards Compl' 

Supports for all Ind 1 

a"t Scalability and 

jitry Transaction Integrity 

Standards 

Seamless Integration 

with Enterprise 

Internal Systems 

Personalization for 

each Customer 

, Secured Transactions 

and Connectivity 

Figure 9.8. — Services of a typical integration broker


data. They have to enable A2A (application-to-application), B2B 

(business-to-business) and B2C (business-to-consumer) integration, 

thereby eliminating the need for an individual software solution for 

each type of integration. 

For small to medium size organizations that do not have the resources 

to implement advanced B2B systems, integration brokers should provide 

functionality for rapidly developing B2B portals to enable Web-based 

participation in business processes. 


Integration brokers should provide the ability to create, test, deploy, 

publish and manage Web services and subscribe to a business partner's 

Web services as an out-of-the-box solution. This would enable the 

enterprises to quickly convert the existing applications into Web 

services. 

9.4.3. Interoperability 

Integration brokers should provide seamless interoperability with existing 

applications, irrespective of the programming language (such as Java, 

C, C++ and COBOL) in which they were developed and the platform 

(such as Windows, Unix and Mainframe) they run on. 

9.4.4. Open architecture 

Integration brokers should provide open, non-invasive and scalable 

architectures that support all the leading distributed computing 

architectures such as COM+, CORBA and J2EE. 

9.4.5. Support for all communication protocols 

Integration brokers should provide support for all the protocols of 

transmitting data for B2B application integration (see Figure 9.9). Some 

of the most commonly used communication protocols include FTP, 

HTTP, HTTPS, EDI, e-mails (POP, SMTP), WAP, SNA and TCP/IP.

*fil s 

;-r a d 

JMS 

HTTP 


: ..._Broke.r 

FTP 

Large Enterprise t 

Email 


-if 11 ! 

Large Enterprise 

Medium Enterprise 

i 

Small Enterprise 

Small Enterprise 

Figure 9.9. — Exchange of data in a typical B2B scenario 

As depicted in the figure, in a typical B2B scenario, a company can 

exchange data with other companies through multiple channels 

9.4.6. Directory services 

As seen in the multi-hub architecture figure, a real world implementation 

is completely distributed in nature with multiple instances of integration 

brokers connecting several applications and middleware resources. 

Directory service of an integration broker is like yellow pages that 

maintain an index of all source and target applications along with their 

location, communication protocol and use. It provides a single point of 

entry, also known as a gateway, along with search facilities for all the 

applications and resources connected by the broker. 

9.4.7. Trading partner management and 

personalization 

Integration brokers should provide a metadata repository, which can 

store the definition, preferences and technical specifications (such as


communication protocol, XML/EDI standard, delivery channel and 

security requirements) unique to each trading partner relationship. Storing 

all this information would greatly increase the speed of conducting 

business and would enable companies to offer personalized services to 

each customer, supplier and distributor. 

Usually integration brokers provide a graphical administration tool, 

which lets the users define and manage relationships (i.e., adding or 

removing a new partner, granting and revoking access to privileges, 

etc.) with each trading partner. 


Integration brokers should provide a complete security solution, using 

encryption, PKI, digital authentication, digital certificates SSL and S/ 

MIME encryption. They should also maintain a transaction audit trail, 

through which data privacy, data integrity and transaction non-repudiation 

(i.e., non-repudiation of origin and non-repudiation of receipt) can be 

ensured. 

9.4.9. Scalability 

Integration brokers should provide a scalable platform that can support 

a company's business today and for years to come. They should be 

optimized for multi-processor systems and enable load balancing and 

failover solutions through a clustered architecture. 

9.4.10. Transactional integrity 

Integration brokers must provide transactional integrity (event-based 

processing, exception handling and built-in recovery) at every step, 

activity and node for each transaction and business process that flows 

through them. 

Typically, a business transaction is composed of several logical units 

of work and each unit of work must be completed successfully in order 

for the transaction to be committed. If even one unit of work fails, the 

whole transaction fails and all completed units of work have to be 

rolled back (reversed).


Since a business transaction may involve updating multiple databases, 

it may take a long time to complete. If a database being updated by an 

application through messages is unavailable, the integration broker should 

store the message and make it available to the application when the 

database is up again. 

9.4.11. Integration broker connectivity 

Table 9.2 shows the connectivity that an integration broker should 

provide (see Figure 9.10): 

Application Adapters 

Language Adapters 

Database Adapters 

Mainframe Adapters 

E-commerce Packages 

Middleware 

Communication Protocols 


Security 

Table 9.2. Integration broker connectivity 

Clarify, Oracle, SAP (SAP EDI, SAP ALE, 

SAP AMS), Siebel, Remedy, PeopleSoft, 

Portal Software 

ACTIVEX/COM, C/C++, CORBA IDL, 

EXECUTABLE, FORTE 4GL, JAVA, HTML/ 

WEB AND XML 

Oracle, Microsoft SQL Server, ODBC, IBM 

Universal Database (DB2), Sybase 

CICS/COBOL, IBM MQ SERIES,CICS/PL/1, 

EDA/SQL, IMS 

Ariba, Broadvision, Commerce One, Blue 

Martini 

COM+, CORBA, MQSeries, MSMQ 

E-mail (POP and SMTP), FTP, HTTP, HTTPS, 

LDAP, NFS, TCP/IP, WAP, SNA 

CICS, IMS, Screen Scraping — CNT 

Enterprise/Access 

Digital signatures, digital authentication, X.509 

digital certificates, RSA SSL (Secure Socket 

Layer), Access control lists (ACLs), Audit 

Logging, S/MIME


Operating Systems 

Industry Standards 

Web/Portals 

Prepackaged Integration 

Solutions 

Business Rules 

>, Formulas Actions Conversion •' 

/ Name Value Fixed Length\ 

| Message Transformation 1 j 

\ Object Streams Variable 

Table 9.2 {Continued) 

AIX, Compaq Tru64, IBM AS/400, IBM RS/ 

6000 IBM-AIX 4.3.3 HP-UX 11, Linux, NT, 

OS/390, Solaris, Siemens-Nixdorf/Pyramid, 

Windows 2000 

XML, CXML, XOCP, XCBL, XI2, SWIFT, 

HL7, ASC X12, EDIFACT, ROSETTANET, 

XML DTD, XML SCHEMA, HTML, SOAP, 

SAP-IDOC, SAP-BDC, AL3, X409, ASTM, 

ASN.l, COM+, CORBA, EJB, JSP, SGML, 

JMS, XSLT 

Apache Web Server, ATG Dynamo, CGI 

Web Servers, DataChannel Portal Server, 

iPlanet Web Server, iPlanet Application 

Server, Microsoft IIS Web Server, IBM 

WebSphere 

Broadvision- SAP, Broadvision- Siebel, 

ONYX-SAP, ONYX-PeopleSoft, PeopleSoft- 

SAP, Siebel-SAP, Clarify, Baan, Oracle 

Applications, Portal, Remedy 

EDI ebXML BtzTalk\ 

Standards 1 j 

, Swift cXML OASI5 X12 


Broker 

CUM Internal Accounting 

I ! 

Applications 

. hRP SCM Legacy Fi 

• Sybase MS-Access Informix 

Databases 

is Oracle SQL Server Db2 

Figure 9.10. — Integration broker connectivity

9.5. Selecting an Integration Broker for 

Your Company 


An integration broker forms the guts of any company's B2Bi 

implementation as it sits right in the center of B2Bi architecture 

with some serious responsibilities that include translating messages, 

applying business rules, making control decisions and providing scalable 

throughput. All the critical business applications of an enterprise are 

connected to the integration broker and any sort of downtime for it 

can have serious repercussions for a company's business. The right 

selection of integration broker can make or break a company's B2Bi 

implementation since it decides how much custom coding is required 

in-house by the IT staff, how much the company will have to spend in 

buying custom adapters for applications, how flexible the solution will 

be and how the system will perform in a real world business scenario. 

All this will have a major impact on the return on investment (ROI) for 

the company. 

With so many integration brokers available commercially, companies 

have to face tough choices as far as their selection is concerned. Factors 

such as sophistication of BPM tool, availability of application adapters, 

messaging capabilities and scalability play a role in the selection process. 

All these factors may have a different weight and order of importance 

in different companies. 

The provision of application adapters of an integration broker 

determines its horizontal adaptability within a company. The more the 

horizontal adaptability, the higher the number of application-to-application 

and peer-to-peer connections the broker can support. Consider only 

those integration brokers that provide adapters for your internal 

applications, otherwise true end-to-end connectivity cannot be achieved. 

For instance, if you have SAP as the ERP system, you should only 

consider integration brokers that offer an adapter for SAP. 

The provision for different types of middleware determines the 

vertical adaptability of an integration broker. Support for the key 

middleware technologies, especially the ones existing within your 

company is another important feature that you should consider before 

buying an integration broker.


Another important factor to consider is the scalability of the 

integration broker. The performance of integration brokers under heavy 

load with a large number of concurrently connected users is a key 

factor in planning a development and deployment strategy. Based on 

your company's requirement, the integration broker should be able to 

handle a few thousand message transactions per day to hundreds of 

thousands of message transactions per day without significantly affecting 

the performance, i.e., it should have a high throughput of messaging 

and processing and low latency. 

Furthermore, in B2B messaging applications exception handling is 

critical and a good integration broker should provide strong exception 

handling. 

Other external factors specific to your company, such as the vertical 

industry you belong to and application domains with which you wish to 

be integrated, also play a major role in the selection process. 

By considering these parameters, you will be able to select the 

product which best matches your requirements today, as well as handling 

your future requirements. 

9.6. Leading Integration Brokers 

Here is a brief review of components and features of some of the 

leading integration brokers: 

9.6.1. Microsoft BizTalk Server Suite 

Microsoft's BizTalk initiative has three fundamental components: BizTalk 

Framework, BizTalk Server Suite and BizTalk Schema Library. BizTalk 

Framework is a platform-neutral e-commerce framework that is based 

on XML schemas and industry standards. BizTalk Server, a member of 

the Microsoft .NET enterprise server family, is Microsoft's flagship 

product, which enables internal (EAI) and external (B2Bi) integration 

of enterprises. It includes a suite of tools and services for visually 

designing, building and maintaining business processes and securely 

integrating applications, independent of their operating system, 

programming model, or programming language. BizTalk Library is a


repository of published schemas submitted by participating companies 

that is maintained on the http://www.biztalk.org/ site. Through this site, 

the schema for any BizTalk message is universally accessible. 

Note: We have provided a detailed coverage on BizTalk Framework in 

the chapter on XML standards. 

BizTalk Server 

The BizTalk Server provides a development and execution environment 

that integrates loosely coupled, long-running business processes and 

applications both within and between companies. It acts as a standard 

gateway for sending and receiving documents across the Internet, as 

well as providing a range of services including BizTalk Orchestration 

Service and BizTalk Messaging Service that ensure data integrity, 

delivery, security and support for the BizTalk Framework and other key 

document formats. 

Integration of BizTalk Orchestration Services and BizTalk Messaging 

Services enables the secured and controlled exchange of documents and 

messages between trading partners and internal applications by using 

multiple transport services. 

BizTalk Messaging Services — The messaging services include sending, 

receiving, parsing and tracking documents; receipt generation and 

correlation; and data mapping, integrity and security. 

BizTalk Orchestration Services — The orchestration services enable the 

creation and orchestration of business processes that span time, 

organizations, applications and people. The services include the 

integration of long-running business processes with the applications that 

run those business processes. An executable business process file called 

an XLANG schedule provides the integration. 

An XLANG schedule is a business process implemented by 

connecting each step in the process to a technology component or 

service that executes the step. An XLANG schedule is then run by a 

service called the XLANG Scheduler Engine, which controls the 

instantiation, execution, dehydration and rehydration of an XLANG 

schedule, or multiple instances of one or more schedules.


The BizTalk Server Suite toolset includes two important modules: 

BizTalk Mapper and BizTalk Editor. 

BizTalk Mapper 

BizTalk Mapper is a tool for creating maps, which define the 

correspondence between the records and fields in one specification and 

the records and fields in another specification (see Figure 9.11). A map 

contains an XSL style sheet that is used by the BizTalk Server at 

runtime to perform the transformation described in the map. The tool 

enables the visual creation of maps by providing drag and drop 

functionality through which users can drag a connecting line from an 

element in the left window (source window) to the target element in the 

right window (target window). 

HH BizTalk Mapper - InvoiceToPayment.xm! 

pie Edit yiew Tools Help 

:16a -ilk- 

Figure 9.11. — BizTalk Mapper

BizTalk Editor 


BizTalk Editor is a tool for creating, editing and managing document 

specifications, which are based on industry standards (such as EDIFACT, 

X12 and XML) or on flat files (delimited, positional, or delimited and 

positional) (see Figure 9.12). Document specifications define a way to 

translate between the document's original data format and the server's 

internal XML format. The specifications can be created based on a 

specified template, an existing schema or from scratch. 

This tool can also be used for directly uploading BizTalk Framework 

compliant XML-schemas to BizTalk library through Web Distributed 

Authoring and Versioning (WebDAV — an extension to the HTTP 1.1 

standard that exposes a hierarchical file storage media, such as a file 

system, over an HTTP connection). The trading partners can then 

download and access this schema. 

IS Microsoft BizTalk Editor (PurchaseOrderRequestGuideline.xml) 

£7 File d Edit Jp View f "Tools*: Help 

DB0|-«tk..m y. £ d,, x l#l 

- \> Contactlnfo 

n ContactType 

1 ContactName 

*• ContactNumber 

- 11 Buyer 

- ;i Address 

U Name 

!>' Addressl 

• t Address2 

n City 

1 State 

»T PostalCode 

! i Country 

-i \:> Contactlnfo 

M ContactType 

i! ContactName 

' ContactNumber 

+l i i( InvoiceTermsOfSale 

-: j ii Item 

- ii>; ItemHeader 

ij LineNumber 

" Quantity 

•' Price 

H UnitOfMeasure 

"•• BuyerPart 

'•i VendorPart 

[ Declaration ^^^Namespacel 

Property I Value 

Required , Yes 

Start Position 

End Position 

Max Occurs | 0 

Min Occurs 1 

- 


Trading 

Partners 

e*Xcharoe 

Partner Manager 

Partner Profiles 

B2B Protocols 

Audit Trail 

E-security 

e*Insight 

Partner Manager 

Model 

Monitor 

Manage 

Optimize 

e*Index 

Paitnei' Manage) 

Auto Matching 

Cross Indexing 

Data Mgm t 

e*Gate Integrator " 

Guaranteed Data Distributed Centralized 

Messaging Transform Deployment Management o 

t> a D 

ft 

m i S- 

Packaged Web/E-commerce Communications 

Application Application Protocols 

Legacy 

Systems 

Figure 9.13. — SeeBeyond e-Business integration suite 

9.6.2. SeeBeyond eBusiness Integration Suite 

Web & Portal 

Connectivity 

SeeBeyond's integration solution is based on message bus architecture. 

The SeeBeyond eBusiness Integration Suite consists of the following 

components (see Figure 9.13): 

e*Gate Integrator — an integration platform based on component-based 

network centric bus. 

e*Xchange Partner Manager — a tool for trading partner relationship 

management that speeds up the whole process of new partner creation, 

maintenance of existing partner relationship and profile management for 

personalization. It offers secured connectivity for a wide range of 

communication protocols. 

e*Index — enables the identification of unique customers across all 

internal disparate applications. It enables the sharing of customer data 

across all applications by creating a cross-index of a local identifier 

assigned by each application to the same customer. 

e*Insight Business Process Manager — a BPM solution bundled with 

the integration suite, which enables design, execution and real-time 

monitoring of a company's internal and external business processes. It 

also includes a decent reporting tool.

Hading 

Partner 

' Enterprise 

Systems 

ERP 

System 

CRM 

System 

Mairfram 3 

Apt* 

Database 

JT 

ERP 

System 

£ 

P 

webMethods BZB 

Integrator 

(Build, Mirage, Publish) 

T 

webMethods B2B Sa ver 

KP 

Mainftame 

Apps 

Database 

CRM 

Future 

wAMahodsHZB Core Sendees 

Alapte-s 

6tobat2tI» : CoODany 

Process 

Manager 

Business 

Logic 

• Loggng/ 

Reporting 

• Routing 

• Processing 

• Validation 

IF IF IF IF 

Mairfram e 

Apps 


Core Services 

If IF 

webMethods 

BZB 

Figure 9.14. — webMethods B2B platform 

9.6.3. webMethods B2B platform 

webMethods 

Enterprise 

Internet 

1> 

HTML 6, XML 

VUebSite 

webMethods integration solution (see Figure 9.14) contains adapters for 

several leading applications, such as Baan, Oracle, PeopleSoft, SAP, 

Siebel and i2. The B2B solution consists of two main components 

which work together to create and execute service calls between business 

applications in use throughout the integrated network. 

webMethods B2B Integrator — a user-friendly, graphical environment 

that allows the users to visually design, define, maintain and administer 

B2B services, business processes, workflows and data transformations. 

A neat feature of this tool is the ability to do integrated testing with the 

B2B server. 

webMethods B2B Server — an integration server that provides an 

environment for executing processes and services as defined by the users. 

It enables B2Bi through secured flow of information between companies, 

their trading partners and trading networks. The server also supports 

several data formats, communication protocols, platforms and standards.


WEBMETHODS AT WORK WITH JUNIPER NETWORKS 

Introduction 

Juniper Networks is a perfect example of medium size companies 

using the Internet and becoming an e-business to compete effectively 

against larger competitors. In order to go head-to-head with its 

powerful rivals, Juniper Networks needed business-to-business (B2B), 

business-to-consumer (B2C) and EAI capabilities, to create a realtime, 

'continuous commerce' environment. To build this competitive 

advantage, Juniper selected the webMethods B2Bi solution suite, a 

comprehensive offering that enables business integration within the 

enterprise and externally with trading partners. 

Matching a Competitor's Capabilities 

Juniper Networks designs, develops and markets a new class of 

integrated silicon- and software-based routing systems for wide-area 

network (WAN) solutions. The company's Internet backbone routers 

enable Internet service providers and other telecom service providers 

to meet the demands of the rapidly growing Internet. For long-term 

success, however, Juniper must continue to offer its customers not 

only superior products, but also e-business capabilities that match or 

exceed those of key competitors. 

In formulating its e-business strategy, Juniper established several 

goals. They included creating a reliable, scalable, secure system of 

integrated applications; ensuring rapid deployment that leverages their 

Internet protocol infrastructure; matching the capabilities of their 

competitor's customer-facing applications; and eliminating batch 

processing of information in favor of real-time processing to increase 

responsiveness to customers. 

But several obstacles stood in the way of Juniper reaching its 

goals. Common data between applications was not synchronized and 

there was no method for building a multi-step business process that 

would span the company's mission-critical applications. Those 

applications include QAD for order management and distribution, 

Clarify for customer service, Selectica for product configuration, a 




custom Java servlet application for quoting and enCommerce for 

Web customer authentication. 

In addition, Juniper works with numerous contract manufacturers 

to produce products and components, so it required a way to link its 

internal business processes with critical trading partners. In particular, 

Juniper needed to improve its Available-to-Promise (ATP) application 

to streamline the Purchase Order/Change Order process and ensure 

immediate answers for customers about product availability and order 

fulfillment. In the past, this manual ATP process — which required a 

significant amount of back-and-forth communication as well as 

duplicate data entry — could take anywhere from three days to a 

week to complete. 

Integrating Internal Applications for e-Business 

After evaluating a range of potential solutions to integrate its internal 

business processes, Juniper selected a combination of webMethods 

Enterprise as its EAI solution and webMethods B2B to handle 

transactions with trading partners beyond the firewall. 

webMethods Enterprise was selected by Juniper for a variety of 

reasons: 

• To provide a flexible, scalable platform for its network commerce 

initiative; 

• To provide a fast return on investment and very rapid 

implementation; 

• To solve the problems of synchronizing data between applications 

and building and automating multi-step, cross-application business 

processes; and 

• To keep pace with the rapid change in the e-business marketplace. 

With webMethods Enterprise, they could easily integrate new bestof-class 

applications as they emerge. The architecture enabled 

them to swap applications they were currently using for better 

ones or add new applications — all without the time-consuming 

work of rewriting point-to-point interfaces. 



Delivering the Benefits of Continuous Commerce 


With webMethods Enterprise as its hub, the Juniper e-business system 

is already having a positive effect on the company's results. Juniper 

now updates, in real-time, a wide range of information customers can 

view over the Web, including customer discounts, promotions, quotes, 

quote-to-order status and shipment-to-order status. 

As the central control point, the vast majority of business created 

by Juniper touches the webMethods Enterprise system. The revenues 

have tripled since the system became operational, even though no 

employees have been added to its order administration staff. Customers 

enter information via the Web and that information immediately 

becomes available throughout the company. The process is very 

efficient and has eliminated the costly, time-consuming and separate 

forecast processes for sales, finance and manufacturing. 

Automating the B2B Supply Chain Allows Real-Time ATP 

Juniper also enhanced its e-business initiative by integrating trading 

partners within its supply chain. The company carries on a virtual 

manufacturing operation, outsourcing its manufacturing to vendors, 

whose information systems can now be linked directly with Juniper's 

via webMethods B2B for RosettaNet. Using the webMethods solution 

(see Figure 9.15), Juniper was able to capitalize quickly on standard 

Soicetron Trading Partner 

(Manufacturing Using webMethods 

System) B2 B for Rosetta Net 

|§f B| 


Selectica 

(Product 

Configurator) 

webMethods 

B2B for Portals 

Nebs cape «ut Enterprise 

(Web Server) 

JUNIPER NETWORKS 

Figure 9.15. — webMethods at work with Juniper networks 

Clarify 

(Support) 

H 

| 

(Financial 

System) 




RosettaNet Partner Interface Processes (PIPs) for Quote and Order 

Entry. 

The webMethods solution integrates Juniper's applications and 

automates cross-application business processes both inside and outside 

their enterprise, enabling the company's highly advanced eBusiness 

operation to compete efficiently with larger competitors. 

Juniper anticipates its integrated eBusiness will reduce IT costs 

year after year by an amount equal to approximately 2% of the 

company's revenues. The system is also creating satisfied customers; 

Juniper consistently receives a rating of 4.5 out of a possible 5 in 

customer satisfaction — the highest rating of any company in its 

industry. 

Juniper's webMethods solution includes the following products: 

• webMethods Enterprise; 

• webMethods Enterprise Adapters: Oracle, ODBC, Clarify, Java 

Agent; 

• webMethods B2B for Portals; and 

• webMethods B2B for RosettaNet. 

Source: Condensed from Juniper Networks Finds Easy Integration with Webmethods, 

ScreamingMedia, Serverworld 


WebLogic Integration provides a single, enterprise-class platform that 

supports all the leading development languages, communication protocols 

and standards, including Java and J2EE (Java 2 Enterprise Edition) (see 

Figure 9.15). It also supports leading B2B protocols, including 

RosettaNet, cXML (Commerce Extensible Markup Language) and XOCP 

(Extensible Open Collaboration Protocol). 

BEA WebLogic Integration consists of four key functional areas: 

Application Server — a J2EE-based application server, which provides 

infrastructure, functional capabilities and underlying services, including


Customers Partners 

O 

Custom Applications 

Suppliers 

0 

FIREWALL 

¥ T 

Employees 

fl 

If 

Third-party Applications! 

Enterprise 

Application 

i> ER.P CRM 

Business web services BEA WebLogic Integration 

SCM Custom 

•M-V 

Simple Web Services 

HR. Legacy 

BEA WebLogic Server 

Figure 9.16. — BEA WebLogic Integration platform 

security, fault-tolerance, messaging and transactions for enterprise-wide 

Web and wireless applications. It enables the creation of simple Web 

services based on point-to-point connectivity and messaging. 

Application Integration — a solution based on the J2EE Connector 

Architecture (J2EE CA). It enables organizations to add and integrate 

new applications with other enterprise-wide applications such as SAP 

R/3, Siebel and PeopleSoft quickly. 

Business Process Management — a component that adds BPM 

functionality to the integration solution. It integrates business processes 

involving systems, applications and human decision-makers. 

B2B Integration — a functional area in WebLogic Integration that 

enables rapid connectivity with business partners and provides a highly 

process-oriented, secured environment to manage B2B interactions. At 

the core of this component are Web services. B2B Integration is built 

upon and significantly enhances the simple Web services supported by 

the WebLogic Server core.

9.6.5. ROI on integration brokers 


Integration brokers have a very high price attached to them. The actual 

implementation of an integration broker in a company can range from a 

minimum of $350,000 to millions of dollars. Companies have to be 

extremely conscious about having at least a rough estimate on their ROI. 

An ideal integration broker solution maximizes the ROI by providing 

technology independence and leveraging existing infrastructure, which 

enables existing applications to continue to operate unchanged. In 

addition, it enables mission-critical communications that gracefully handle 

network and application failure and connect packaged applications with 

legacy systems and databases. 

Integration brokers reduce the cost of maintaining application integration 

solutions by imposing a structure on the integration development process. 

Without integration brokers, a small change in an existing application can 

cause a rippling effect on each individual interface that connects it to 

only a single application. But, with an integration broker, only a single 

interface that connects the application to the broker needs to be changed. 

Integration brokers also significantly reduce the cost of in-house 

custom coding required to integrate applications, as it provides prebuilt, 

pre-configured adapters for applications. According to the Gartner 

Group, when implemented well and managed effectively, integration 

brokers reduce the amount of time (and money) required to develop 

interfaces between applications by as much as 25 percent (i.e., for 

simple interfaces) to 43 percent (i.e., for complex interfaces). 

There is a direct relationship of cost savings and the complexity and 

heterogeneity existing within an enterprise prior to the implementation 

of an integration broker enabled B2Bi. Enterprises with more diverse 

computing environments, platforms, systems and applications realize 

the cost savings and reduction in development efforts quickly. 

The total cost savings to a company will increase with the time that 

it has deployed an integration broker. 


Integration brokers have emerged as a bridge between heterogeneous 

applications and systems that enable sharing of an organization's


information across part or all of the extended enterprise. Integration 

brokers perform the tasks of interfacing (extract the data in and out of 

applications), transforming (convert the semantic information of the 

data before passing it on other applications), distributing (move the data 

between applications), routing (send the data to the appropriate receiver), 

managing (create the workflows for business processes) and storing 

(store the data/messages in a message warehouse). 

Integration brokers substantially reduce the time and effort required 

to implement and maintain new application interfaces. They allow 

enterprises to leverage a single platform and reusable components across 

multiple applications. 

Several vendors offer integration broker platforms. Although there 

are similarities in their products, there also some significant differences. 

Companies have to carefully choose which product best suits their 

current IT infrastructure and internal and external integration goals, 

both short-term and long-term.

Chapter *| Q 

Internet Security 


B2B integration involves significant security risks, as it involves the use 

of the Internet for conducting business. Security and privacy controls 

are becoming mandatory before access to participation in huge B2Bi 

implementations. 

In this chapter, you will learn about the fundamentals of Internet 

security, different security risks involved in B2B integration and comprehensive 

solutions to mitigate them. We have also discussed how 

organizations can shield themselves from the outside world and make 

secure transactions involving payments over the Internet. 

287


10.1. Internet Security (E-Security) Critical 

for B2Bi 

The Internet has revolutionized the ways in which companies do business. 

B2B e-commerce is undeniably efficient, inexpensive and flexible. However, 

it is vulnerable to a range of security risks. As B2B e-commerce 

becomes more widespread, security tends to be critical in achieving 

seamless communications between trading partners. It is not just a 

requirement, but in fact the foundation on which B2Bi will be built. 

Information recorded electronically and available on networked 

computers is more risk-prone than if the same information is printed on 

paper and locked in a filing cabinet. Intruders do not need to be 

physically present at that location and may not even be in the same 

country or continent. They can silently steal or tamper with electronic 

files and hide evidence of their unauthorized activity. 

A recent study on Internet Security, conducted by the Datamonitor 

Group, has found that companies have a very low awareness of the 

need for e-security. Over 50 per cent of businesses spend 5% or less of 

their IT budget on security technology, with just a mere 10% spending 

over 20% of their IT budget on security. So, the fact is that many 

companies will experience a major loss due to lax security. 

Neglecting adequate security measures in B2Bi applications, which 

exposes a company's network to customers and partners, may land a 

company in hot water. In a B2Bi environment, even simple mistakes 

could lead to leakage of data that no trading partner would ever 

tolerate. Consider a scenario where a mistake or wrong configuration 

in a company's systems causes confidential pricing agreements or 

customized catalog data sent by a supplier to leak out. The supplier's 

other customers may cry foul, ending their business relationships with 

the supplier altogether. The erring company may have to bear the 

liability and make up the difference in sales. 

Thus, a company participating in B2Bi has to convince its trading 

partners that it can be trusted with their data. It has to continuously 

detect, correct and eliminate risks to mission-critical B2B systems and 

data. In fact, security and privacy controls are becoming mandatory 

before access to participation in huge B2Bi implementations.

Internet Security 289 

10.2. B2Bi — Makes a Company Highly Vulnerable 

to Security Risks 

At the core of B2Bi is communication — the real-time exchange of 

sensitive corporate data among trading partners. If the security within a 

company is not good enough, it not only risks exposure of its data but 

also that of its trading partners. 

Below are some key reasons that make B2Bi considerably vulnerable 

to security risks: 

10.2.1. Complex nature of applications 

B2Bi involves a variety of applications and software components. A 

typical system consists of custom-developed applications, off-the-shelf 

components and vendor- provided components, all integrated together. 

It is very difficult to evaluate each component's robustness from a 

security point of view and there may be potential weak points that go 

unnoticed. 

10.2.2. Anonymous relationships in 

B2B e-commerce 

Anonymity, a key characteristic of B2B e-commerce, poses a high 

security threat to online transactions. Given the dynamic nature of 

relationships in B2B e-commerce, a company may deal with several 

kinds of trading partners, and some of them will not even be known 

beforehand. This greatly increases the risk of impostors, posing as 

trading partners, trying to sneak into the company's corporate networks. 

10.2.3. Software undergoing frequent change 

Due to the large number of applications involved in a typical B2Bi 

environment, the amount and frequency of adjustments that have to be 

made to the whole system is considerably high. This increases the risk 

of potential bugs introduced into the system.


10.2.4. Human factor involved 

Applications supporting B2Bi are accessible to many people, from the 

customer service representatives at the call center to sales executives 

equipped with wireless laptops and, hence, chances of someone 

accidentally or intentionally creating a security breach are higher. 

10.3. Employees and Other Insiders Pose the 

Biggest Threat 

Companies do not have to look too far to identify the biggest threat to 

their e-security. It is right within their organization, in front of their 

% of respondents experiencing 

these breaches in the past 12 months 

0% 10% 20% 30% 40% 50% 60% 70% 80% 

Installation/use of unauthorised S/W 

Infection of company equipment via viruses/ 

malicious code/executables 

(deliberate or accidental) 

•••••••••^••••••i 63% 

Use of company computing resources for 

illegal or illicit communi cation or activities 

(Porn surfing, e-mail harassment) 

•lllliMllfMtiPI¥TffWIP"«'«"'' 58% 

Abuse of computer access control 

l^^MM^BMMMMIilMllMiiM— 54% 

Installation/use of unauthorized 

hardware peripherals 

Use of company computing resources for 

personal profit (gamblling, spam, managing 

personal e-commerce site, online investing) 

3aHHRHWttK 42% 

Physical theft, sabotage or Intentional 

destruction of computing equipment Unsure 

24% 35% 

Electronic theft, sabotage or intentional 

destruction/disclosure of proprietary 

data or information 

13% 

Fraud 

Were these breaches 

deliberate or accidental? 

70% 

Deliberate 

17% 

Accidental 

48% 

Source: Information Security, September 2000 Issue, Survey 2000 

Figure 10.1. — Insider breaches 

76%


own eyes — it is the staff and insiders (see Figure 10.1). Electronic 

sabotage, theft and disclosure of proprietary knowledge by insiders are 

growing at an overall rate of a whopping 41% per annum. 

10.4. E-Security Strategy 

E-security strategy should be an integral part of a company's overall 

B2Bi strategy. If a company wants to participate in B2Bi, it will have to 

forgo the old strategy of completely hiding the data if it cannot be 

protected. The new strategy calls for the implementation of a security 

solution that enables enterprises to deliver secure e-business solutions and 

personalized access management by controlling access to applications, 

resources and data. It should give them the ability to extend their 

internal systems to their business partners without quickly and easily 

compromising on security or performance; incorporate the right selection, 

configuration and use of security products and their integration with 

legacy systems; and establish dynamic security policies. As a part of 

their e-security strategy, companies have to: 

• Determine critical assets such as corporate networks, devices, 

applications and data; 

• Evaluate the potential security threats in the B2B environment; 

• Secure the assets by properly selecting and deploying a right security 

solution, which provides a high return on investment while scaling to 

their security needs; and 

• Evolve the security solution by constantly reviewing the business 

environment, B2Bi goals, current threats and the latest technological 

changes. 

10.5. Basic Security Services in B2Bi 

E-security, in light of B2Bi, is about protecting an enterprise, while 

extending the business information and data to cross-enterprise 

applications and systems. In B2Bi, the focus is on building trusted 

relationships with trading partners, and the importance of maintaining 

this trust cannot be over-emphasized. Whenever data communication


takes place between different companies, there is some risk involved. 

The major concerns are: 

• Someone may intercept the message and breach its privacy; 

• Someone may impersonate a company and send a message under its 

name and signature; 

• Someone may change the contents of the message in transit; and 

• The sending company may, later on, deny having sent the message. 

To reduce these risks, the following security services must be ensured 

during B2B communication: 

• Confidentiality — assurance that the message is private and its contents 

have not been disclosed to the outside world; 

• Authentication — proof that the message was indeed sent by the 

company with whom communication was taking place; 

• Integrity — complete assurance that the message was not tampered 

with or accidentally altered during transit; and 

• Non-repudiation — the message must be binding on the sending 

company so that it cannot deny having sent it at a later point. 

Failure in ensuring any of the above features will result in the whole 

transaction being compromised and ultimately undermine the confidence 

of businesses and consumers in B2Bi technology. 

10.5.1. The strength of the chain is as strong as its 

weakest link 

Besides securing the data transaction, i.e., the data while it passes from 

one enterprise to the other, the data must be secure at the end-points as 

well. To elaborate further, the data resides in the sending company on 

some physical system, maybe its Web server, or some other server. 

Also, when the receiving company gets the data, it stores it in some 

physical location. Unless strict measures are taken, this data can fall 

into unauthorized hands, by someone breaking into the internal LAN of 

either company, through the Web server or through the operating system. 

Therefore, each aspect of the system must be equally secured. There is


no point in securing just the communication channel, if the intruders are 

able to access the information by breaking into internal systems of the 

company. 

10.6. Key Concepts in E-Security Solutions 

Some key technologies that have emerged as the foundation of 

e-security are: cryptography, digital signatures/certificates and firewalls. 

In this section, we will take a closer look at these technologies and 

understand the role played by each in creating a secure environment for 

an enterprise. 

10.6.1. Cryptography 

Cryptography, also called encryption, protects the privacy of sensitive 

information being transmitted over the Internet. It ensures that the 

information is not intelligible if it falls into the wrong hands. While 

cryptography has been in existence since ancient times, its level of 

sophistication has increased, commensurate with the increase in risks. 

Today's cryptography uses sophisticated mathematical formulas and 

computer algorithms. 

The main elements of cryptography are: 

• Original Text — the precise contents of the message; 

• Cipher Text — the form in which the message appears after being 

encrypted. This is not humanly readable; 

• Encryption Algorithm — the algorithm or mathematical formula used 

to convert the original message into cipher text; and 

• Key — the element used to encrypt and decrypt the message. Every 

encryption algorithm makes use of a key. Depending on the key used, 

the same algorithm will produce different cipher text for the same 

message contents. 

Encryption is done to secure not only text, but also video, sound, 

etc. — any form of communication across the Internet.


Secret 

Secret 

Message Encryption 

with 

Company A Private Key 

Decryption 

with 

Private Key 

Message 

Company —J B 

Figure 10.2. — Private key encryption 

10.6.2. Private key encryption 

Private key encryption, also called symmetrical encryption, was the 

simplest way the encrypted messages were sent in the earlier times. It 

used the same unique code called single key or private key for encrypting 

as well as decrypting the messages. 

Consider a scenario in which Company A wants to send Company B 

a secret message (see Figure 10.2). If a single private key is used, 

• Company A informs Company B about its private key. 

• Company A encrypts the message with its private key and sends the 

message across. 

• Company B makes use of the private key (sent over earlier) to 

decrypt the message. 

This encryption method has several obvious limitations. Firstly, 

there has to be some secure way by which Company A will initially 

communicate the private key to Company B. If an outsider gets hold 

of this private key, the entire communication will be compromised. 

Secondly, Company A becomes completely vulnerable to Company B 

and if Company B wishes it can use this private key to impersonate 

Company A. Finally, this method is not suitable for multi-party communication— 

for example a B2B exchange may be communicating 

with hundreds of companies for which it will have to distribute the 

private key to all the companies; and as the number of companies 

increases, it can be compromised easily. 

The most commonly used private key encryption algorithms are RC2 

(40 bit encryption) and RC4 (128 bit encryption). Both of these were 

invented by RSA Data Security. 56-bit DES is another algorithm that is 

primarily used for unclassified government documents.

10.6.3. Public key encryption 


To overcome the drawbacks of private key encryption, a new algorithm, 

called public key encryption, was invented by Whitfield Diffie and 

Martin Hellman in 1976. 

Public key encryption or asymmetrical encryption uses two keys: 

• One is called the private key, which is held by only one party; and 

• The other is called the public key, which is available to the outside 

world. 

These keys complement each other like a mechanical lock and key. 

The message is encrypted with the public key and can be unlocked or 

decrypted only with the private key. Any company, like Company A, 

wishing to communicate with Company B can encrypt the message with 

Company B's public key and send it across (see Figure 10.3). Thus, the 

two companies do not have to agree upon a key in advance. Since the 

decryption can be done only with the private key, which is known only 

to Company B, even if the message is intercepted, the interceptor will 

not be able to comprehend the message. Thus, the message always 

remains protected using public key encryption. 

Public key encryption comes with its own share of drawbacks; speed 

being the most critical. The keys used are much longer than symmetric 

encryption, hence encryption overhead is much higher and performance 

decreased. 

Among the most popular algorithms available for public key 

encryption is RSA, created by RSA Data Security, which uses key 

lengths from 512 to 1024 bits. 

Secret 

Message 

„ f 

Encryption 

«iith 

Company A Public Key 

of Gompany B 

Decryption 

with 

Figure 10.3. — Public key encryption 

Secret 

Message 

_ p 

Private Key company B 

of Company B


Session Key 

^ 

Secret 

Message Encryption 

t) with 

CompanYA Session Key 

Figure 10.4. 

*ds-~ y 

Cipher 

Text Decryption 

with 

Secret 

Message 

Session Key Company B 

Digital envelope 

10.6.4. Best of both worlds — The digital envelope 

By combining private and public key encryption, we get best of both 

worlds, the digital envelope. 

Consider again a case of Company A wanting to communicate with 

Company B. Company A generates a random private key for the 

communication session. This random private key is called a session key 

since it will be used only for this particular session. The session key is 

encrypted with the public key of Company B and sent to it. Company B 

gets the session key securely, using its private key to understand the 

message. Figuratively, the session key is sent in a secure envelope 

formed by public key encryption (see Figure 10.4). 

Once the session key is established between the two companies, the 

subsequent communication, based on private key encryption, can be 

made using the session key on both sides. This part of communication 

is much faster due to decreased overhead. 

Using a digital envelope, the same level of privacy is achieved as 

public key encryption with better performance of the application. 

10.6.5. Digital signature 

Digital signature is the electronic equivalent of a pen-and-paper signature 

and is used for authenticating the sender of the message. It provides 

a means by which information cannot be repudiated by binding


communication to the person who signed it. It also guarantees that the 

message was not modified since it left the sender. Digital signatures 

rely on public key systems. 

Creating a digital signature 

A digital signature is typically created using what is known as a hash 

function. A hash function is an algorithm that maps values from a large 

domain into a much smaller range. In other words, if we have a typical 

message, which consists of many thousands of bits, the hash algorithm 

can produce a 'digest' of it, which would be about a hundred bits in 

length. Also, it would ensure that even if one bit is changed in the 

message, the digest produced would be different. This 'message digest' 

is encrypted using the sender's private key (usually RSA encryption) 

and the result is called the digital signature (see Figure 10.5). 

The digital signature is attached to the message file and the combined 

message is encrypted with the receiver's public key (see Figure 10.6). 

Receiver's 

Public Key 

Message 

Hash 

Function 

Message 

PMWMS? 

Sender's Private 

Key 

Message 

Digest 

Digital 

Signature 

Figure 10.5. — Creating a digital signature 

Digital 

Signature 

Signed and 

Encrypted 

Secured Message 

Figure 10.6. 

signature 

Encryption using digital


When the receiver gets the message, it performs the following 

actions: 

1. It decrypts the message using its private key (see Figure 10.7). Now 

what it sees is the digital signature and the original message file. 

2. It re-computes the 'digest' from the original file, using the same hash 

algorithm. 

3. It decrypts the digital signature using the sender's public key. 

4. It then compares the decrypted digital signature with the digest that it 

just computed. 

5. If the two are exactly the same, the receiver is assured that the 

message was not changed en route and also that the sender's identity 

is proved (as the sender's private key was involved in the process; 

see Figure 10.8). 

Receiver's 

Private Key 

Secured Message 

Received 

Message 

Digital 

Signature 

Figure 10.7. — Decryption using digital signature 

Hash 

Function Sender's Public 

Key 

Message 

Digital 

+ Signature 

Message Message 

Digest Digest 

Pass/ 

Fail 

Figure 10.8. 

message 

Ensuring integrity of the


Message Authentication Codes (called MACs) is another mechanism 

for identifying users. A MAC is an authentication tag (also called a 

checksum) derived by applying an authentication scheme, together with 

a secret key, to a message. However, it is not foolproof, as the receiver 

can also generate these codes and misuse them. 

SIGNING ON THE DIGITAL LINE 

Williams Communications, an Oklahoma-based company, is an example 

of how digitally signed documents can streamline business 

processes. 

Much of the company's correspondence consisted of sensitive 

documents — from employee time sheets and performance reviews to 

contracts and agreements with customers and other companies. All 

these items required physical signatures to ensure their accuracy, 

integrity and validity. However, gathering those signatures meant lots 

of paper, slow cycles and a real loss of efficiency within the company. 

The company decided to use electronic signatures — a technology 

that allows digital documents to be 'signed', keeping them valid 

and secure while retaining the efficiency of electronic storage and 

transmission. Soon after, Williams Communications implemented two 

pieces of electronic signature technology — Approvelt from Silanis 

Technology and a form of public key infrastructure technology from 

Entrust Technologies. The technology not only helped alleviate the 

company's paper-generated internal struggles; it also paved the way 

for faster and easier e-commerce interactions with customers and 

business partners. 

A Changing Landscape 

It sounds like a fine solution to a significant problem, but there was 

an issue: where a manually signed document carried force of law 

behind it, digital signatures often weren't worth the virtual paper they 

were written on. All that changed in June 2000, when Congress 

passed the Electronic Signatures in Global and National Commerce Act. 

The act, effective October 1, 2000, made digitally signed electronic 

agreements as legally valid as hand-signed, printed documents. 

Source: Condensed from Signing on the Digital Line, CIO Magazine


10.6.6. Digital certificates and role of Certificate 

Authorities (CAs) 

All of the above mechanisms of security relied on using public keys 

and private keys for both the sender and the receiver. The question 

arises — where do these keys come from? How does the outside world 

get hold of the public key of a particular party? 

The answer lies in digital certificates, issued by organizations called 

Certificate Authorities (CAs). Certificates can be used to replace passwords 

and login ID's wherever access is to be restricted to certain 

users, such as registered customers. In several applications, certificates 

may replace 'cookies', which have proven unpopular with many Web 

users. 

Any company/individual wishing to communicate securely over the 

Internet can apply to a CA for a digital certificate. It has to send 

its identification information and public key to the CA. The CA will 

verify the authenticity of information and then issue a certificate with 

the given information and public key. To seal the certificate, the CA 

encrypts it with its private key and sends it to the applicant (see 

Figure 10.9). 

In this approach, when Company A wants to communicate with 

Company B, it will ask Company B for its certificate. On receiving this 

certificate, Company A will decrypt the same using the CA's public key. 

It will then read the identifying information on the certificate. If satisfied, 

it will use the public key present on the certificate to send across the 

information to Company B. 

This methodology is not only secure, but requires the sender to 

know only the CA's public key, rather than remember the public key of 

every party it wishes to communicate with. 

The most widely recognized standard public key certificate format is 

defined in the ITU X.509 standard. 

Serial 

Number 

Signature 

N umber 

CA Info 

CA 

Number 

Owner Info 

Owner's 

N umber 

Owner's 

Public Key 

N umber 

Validity 

Period 

Figure 10.9. — Simple public key certificate 

CA 

Digital 

Signature


There are multiple organizations which function as certification 

authorities. Leading among them is Verisign (http://www.verisign.com), 

which caters to institutions as well as individuals. It issues the following: 

• E-mail Certificate — verifies that the e-mail comes from the mentioned 

address; 

• Server Certificate — establishes the identity of a particular Internet 

site; and 

• Code Signing Certificate — used by software companies to sign the 

released versions of their code. 

10.6.7. Using SSL (Secure Sockets Layer) to 

establish secure sessions 

Secure Sockets Layer (SSL) provides privacy, integrity and authentication 

to application protocols such as HTTP by using encryption, message 

digests, digital signatures and certificates. This is very valuable on the 

Internet since it allows a much greater degree of secure communication 

than is available without SSL. Most Web servers and browsers today 

support SSL and implement it automatically, so users using these 

browsers can utilize it directly. 

SSL operates on top of the TCP/IP network layer (see Figure 10.10). 

Therefore, any communication that relies on TCP/IP such as FTP file 

transfer, news protocol (NNTP), remote login sessions (telnet, rlogin, 

rsh) and e-mail (SMTP) can, in theory, be secured by SSL. 

SSL performs the following: 

• Allows an SSL-enabled server to authenticate itself to an SSLenabled 

client; 

HTTP SMTP NNTP 

Application Layer 

Network Layer 

TCP/IP Layer 

Figure 10.10. — Protocol stack for communications


Send a Client Hello 

Send a Server Hello 

Certificate 

Certificate Regue^ 

Server Hello Done 

Certificate 

Certificate Ver if' L, 

Change Ciphers pec 

Finished 

CharêChJpherSpec 

Finished 

Client Server 

Decide on the cipher suite, and set up the 

session ID and other parameters such as 

method of compression and protocol version 

Request the client certificate and if required, 

send the server certificate 

Acknowledge the receipt of client certificate, 

if required 

Exchange the 1 cipher suite and handshake is 

completed 

Figure 10.11. — Simplified handshake sequence 

• Allows an SSL-enabled client to authenticate itself to an SSL-enabled 

server; and 

• Allows both to set up an encrypted connection, i.e., a secure 

communication channel. 

To achieve the above, SSL supports multiple cryptographic algorithms 

called ciphers. The client and server decide upon a set of ciphers or 

cipher suite during their initial SSL handshake (see Figure 10.11). 

10.7. Shielding an Organization from the 

Outside World 

In this section, we will discuss the solutions companies use to shield 

themselves from the outside world. 

10.7.1. Firewalls 

Until now, we have discussed the mechanisms for securing the data in 

transit, i.e., when it is traveling from one company's systems to the 

other. Now we shall look at how a company can prevent the data from 

unauthorized access while the data still lies in its internal systems.

Firewall 

DMZ 

Internet 

t 

Screening router 

Screening Router L^... 

internal LAN 

Network Client Nodes 

Server 

mm 1 


Proxies 

Figure 10.12. — Firewall between internal LAN and the internet 

A firewall insulates a company's internal networks from the outside 

world. It is the first line of defense between the internal LAN and the 

Internet (see Figure 10.12). It works by enforcing an access control 

policy to and from the private network. All messages entering or 

leaving the Intranet pass through the firewall, which examines each 

message and blocks those not meeting the specified security criteria. 

Firewalls can be implemented in both hardware and software, or a 

combination of both. 

10.7.2. Functions performed by firewalls 

The functions performed by firewalls are: 

1. Allow the traffic from the Internet to enter only when it is going 

to a particular set of applications. For these applications, traffic is 

allowed to go only to certain internal addresses (machines) and not


others. These machines have the ability to cope with any threats 

posed by outside requests. 

2. Check the source of the traffic. For some types of incoming traffic, 

it may be necessary to check the source. For example, users coming 

in via TELNET may have to provide their username and password 

or a personal token for identification. 

3. Regulate not just the incoming traffic, but also the traffic going from 

the internal LAN to the external Internet. If a network is compromised, 

then it may be made to send certain data/packets to the outside 

Internet to addresses where it is not supposed to go. Checking where 

data is going from the inside to the outside can halt this kind of 

activity. 

4. Encrypting or checking data integrity for all the traffic to or from a 

network. This 'gateway' type of implementation is also called a 

virtual private network. 

10.7.3. Types of firewalls 

Firewalls generally belong to two classes: network level and application 

level. 

Network level firewalls 

Network level firewalls intercept every packet that attempts to go in or 

out of your network (see Figure 10.13). 

A network level firewall acts at the IP — machine address level. It 

uses screening routers or packet filters. Each network packet contains 

External 

Network 

Di rect Tratt ic 

Possible 

Network 

Laval 

Bastion 

[Optional) 

,=t Ne 

/ (Subnet) 

Figure 10.13. — Network level firewall schematic


the IP address of its source and destination. Packet filters check this 

address information of each and every packet, to determine whether it 

is acceptable or not. The administrators set up the firewall rules on the 

basis of whether it filters the incoming traffic and allows/disallows 

connections. 

Routers, which direct information packets, can provide some firewall 

support because their function is to forward and filter data packets. 

Some sophisticated routers provide additional facilities such as encryption 

features. 

These types of firewalls are usually the least expensive. However, 

they do not offer much flexibility and also slow down the performance 

of the network considerably. 

Application level firewalls 

Application level firewalls work by handling the traffic destined for a 

specific application such as e-mail or FTP, rather than all network 

traffic (see Figure 10.14). 

Application level firewalls are like a relay system between the 

Internet and the internal network; they do not allow direct traffic to 

pass between the two networks. In these, a highly isolated machine, 

called an application gateway, proxy gateway, or proxy server is used. 

This machine runs programs called proxies; a separate proxy is run for 

each Internet service, such as HTTP and FTP. 

Since all interaction of the external users is with the proxies, this 

allows all passwords and internal IP addresses to remain internal, 

making them more difficult to detect and misuse. 

External 

Network 

Network 

Laval 

Figure 10.14. — Application level firewall schematic


With an application level firewall, a company can control which user 

has access to what application and when the user can access it. This 

firewall also performs detailed activity logging. Check Point's Firewall- 

1 is the most widely used application level firewall. 

10.7.4. Considerations in choosing a firewall 

The right selection of a firewall is of utmost importance for an enterprise, 

as it is able to secure the integrity and availability of data and data 

processes. It is very important to perform risk analysis before selecting 

a firewall. The status of each identified risk should be further evaluated 

to determine if it is still a valid risk. If the answer is yes, the firewall 

chosen should eliminate it completely. 

Any firewall that a company chooses has to provide the list of 

features and level of performance that it has identified as mandatory. 

The main considerations in deciding the type and configuration of a 

company's firewall are: 

• Internet Services Required — what services will be required, e.g. telnet, 

World Wide Web, audio or video applications; 

• Additional Features Required — whether encryption will be used; 

• Integration Capabilities — how well does the firewall integrate with 

other products, such as encryption tools; 

• Level of Risks — how closely the information needs to be guarded, 

depending on how sensitive or mission critical the information is; 

and 

• Budget — expenditure permissible for firewall setup and maintenance. 

Although it is difficult to give exact advice, in general application 

gateways are more popular firewalls, due to the level of flexibility and 

control that they provide. 

10.7.5. Enterprise firewall appliance 

An enterprise firewall appliance is a hardware and/or a software device 

that provides robust and comprehensive enterprise security for Internet, 

intranet and extranet traffic. Its deployment and configuration, based on

Firewall 

Function 

Monitor, 

Report 

Writer 

OSKernel TCP/IP 

Private 

Network 

Web Browsers 

'Router 

aproxy http web gate 

i 


Mail Server 

Figure 10.15. — Enigma firewall solution 

Web Servers 

DMZ 

aka 

Server Network 

an enterprise security policy, is extremely rapid, as most of its components 

are pre-installed and pre-configured. These appliances are built 

using the latest security technologies; and provide remote administration, 

the ability to manage multiple firewalls from one location, centralized 

built-in reporting and logging for monitoring all activities and the 

flexibility and scalability to support enterprise level traffic. 

Check Point's Firewall-1, Symantec's VelociRaptor, Watchguard's 

Firebox II and Enigma 2.0 Firewall Appliance are some examples of 

enterprise firewall appliances. 

Figure 10.15 is a simplified reconstruction of the internal workings 

of the Enigma Firewall Appliance. All computers in the private network 

and the DMZ communicate with the proxies. The proxies manage 

connectivity between the networks and all transfers must pass through 

them. There are multiple independent proxies that are tailored to provide 

application specific defenses, such as e-mail, FTP, HTTP and reverse- 

HTTP.


10.7.6. Virtual Private Networks (VPNs) 

Many organizations have several offices situated in diverse locations. 

They have employees who are traveling or telecommuting, as well as 

business partners and customers in remote locations. These organizations 

would like to provide all these entities access to their internal LANs. 

The simplest way of doing this would be to dial-in directly to the 

modems of the organization or access its Remote Access Server (RAS) 

directly, via long distance telephone calls. 

This method is secure. However, it is substantially expensive for 

most companies. The ideal way would be a secure way of getting 

access to the LAN through the general Internet. Internet-based VPNs 

that use the open, distributed infrastructure of the Internet to transmit 

data between corporate sites, provide companies with a mechanism for 

a combination of security and economy (see Figure 10.16). 

Branch Office Branch Office 

Partner Office 

Figure 10.16. — VPN network securing a business, partner company and 

mobile worker


Virtual private networks enable enterprises to leverage the Internet, 

while protecting sensitive business information. With VPNs, companies 

can achieve a significant cost saving of up to 60% over private leased 

lines and 30% over frame-relay networks. 

VPNs have to provide scalability, flexibility and reliable performance 

in order that the companies use them to support access to their missioncritical 

applications. All the components of VPNs should be easy to 

configure and provide seamless integration within the whole enterprise 

security infrastructure. 

VPNs have to provide the following three critical functions to 

ensure security for data: 

• Authenticate — confirm that the data is coming from the source that 

it claims; 

• Secure — restrict read/write access and maintain data integrity of the 

data traveling over the Internet; and 

• Access control — allow only authorized users to gain admission to 

the network 

VPN uses the following technologies: 

• Encryption; 

• Authentication; and 

• Protocol Tunneling — In protocol tunneling, the actual data packets 

are encrypted; then enclosed inside other IP packets and transmitted 

across the Internet. At the destination, there is a special host that 

decrypts them. This tunneling of data is completely transparent to the 

end-users. They feel as if they are directly connected to the internal 

LAN. 

Various protocols are used to carry out tunneling, such as Microsoft's 

Point-to-Point Tunneling Protocol (PPTP), Ipsec protocol and L2TP 

protocol proposed by Cisco and Microsoft. There are several vendor 

products available for creating and managing VPNs, such as IBM 

eNetwork VPN series and AltaVista Tunnel97. Many telecom carriers 

such as AOL and AT&T also offer dedicated services for VPN 

communication.


10.7.7. Check Point's VPN solution 

Check Point's VPN-1 family of products (software-based VPN Gateway 

products, plug-and-play VPN appliances, client-based VPN software, 

VPN acceleration cards and PKI products) helps build state-of-the-art 

Enterprise VPNs, by providing secure Internet-based connectivity to 

corporate networks, remote and mobile users, satellite offices and partner 

sites. 

The key component in the whole family is VPN-1 Gateway (a 

combined package of Fire Wall-1 and VPN-1), which supports high 

availability configurations for IPSec traffic and remote access VPNs 

(see Figure 10.17). It supports all leading PKI products and services 

that are used mainly for extranets, and includes bandwidth management, 

compression and hardware-based VPN acceleration. 

FloodGate-1 

Bandwidth' 

Management 

Authentication pvl^-^^ 

Server t r~Z? 

VPN-1 

Gateway 

Certificate 

Enterprise 

Management 

Console 

Partner 

Site 

IPSec-Com pliant 

Gateway 

Secured By Satellite 

Checkpoint 

office 

Appliance 

Figure 10.17. Check Point's VPN solution 

VPN-1 

SecureClient

10.8. B2Bi and E-Security 


After discussing the fundamentals of e-security, let's review how it 

plays a role in a company's B2Bi plans. 

10.8.1. Revamp your security 

The security solutions that companies implemented in the EDI world 

are rather obsolete. EDI-based communication occurs over VAN and 

with a select few predetermined partners. B2Bi over the Internet changes 

all equations and makes the existing security solutions outdated. 

E-security for B2Bi is much more than just installing a corporate 

firewall. B2Bi requires securing communications (99.99% security level 

is not good enough — it has to be 100% secured) between networks, 

systems, applications and users across the Internet, Intranets and extranets. 

Below are just a few of the features that a company should look for in 

a security solution that would help it achieve the elusive 100% security 

protection: 

• Be a truly all-in-one security system that combines firewall, antivirus, 

intrusion detection and other security necessities into a single 

product that's easier to manage than integrated multiple tools; 

• Provides real-time transaction auditing and monitoring of audit trails; 

• Provides full, customized access to security information reports, 

policies and logs; 

• Interface to add, modify and delete security policy change requests; 

• Support for multiple operating systems such as NT and UNIX; 

• Provides easy-to-use graphical user interface that allows the security 

administrators to review and set entitlements as required, right down 

to the application and object level; 

• Provides a flexible and expandable security architecture, which can 

fit into any company's existing infrastructure; 

• Offers robust access control, cryptography-based privacy and authentication 

of users; and 

• Gives high performance and scalability when the load (i.e., system 

load, user accesses and user authentications) is great.


Commission a DMZ (demilitarized zone) 

As a crucial part of e-security revamping efforts, a company should 

commission a DMZ that is delineated by an external and an internal 

firewall. The external firewall secures the systems inside the DMZ from 

external intruders. It provides access to these systems only to authorized 

parties. The internal firewall, on the other hand, prevents unauthorized 

access to enterprise networks and systems from the DMZ. 

Formulate policies for detecting intrusion 

Formulate corporate security policies that require logging and minute 

level inspection of every inbound and outbound call. This will assist in 

identifying dubious activities and patterns leading to a network or 

system attack. 

Build an effective entitlements management system 

This system should be geared towards setting up the entitlements and 

user access privileges for all the applications, independent of their 

respective platform. Such a system would eliminate the need for 

proprietary security components built into each individual application. 

Implement cross-domain single sign-on 

Single Sign-on (SSO) enables the user to log in (by providing user ID 

and password) just once and then caching that information for the 

whole session until the user logs out. Once the user is logged in 

successfully, the user's identity can be shared and passed on from one 

system to another, thereby making it unnecessary to have a separate 

sign-on for each system. With a cross-domain single sign-on, this 

information can be passed over from one secured domain to another. 

10.8.2. B2Bi software 

Your B2B integration software/server provides the primary source of 

access over the Internet. It acts as an external interface to a company's


corporate network and if not properly chosen can provide easy break-in 

points to hackers. 

As a part of B2Bi strategy, a company should choose B2B integration 

software that has: 

• Wide support and adoption by security vendors; and 

• Flexibility in easily linking existing security solutions in the integration 

solution. 

10.8.3. Security features in the leading B2B 

integration servers 

Security features in some of the leading B2Bi integration solutions is 

as follows: 

webMethods B2B solution 

webMethods B2B solution supports X.509 digital certificates, which 

ensure that business services are accessed and data transactions are 

initiated only by known and specified partners, HTTP Authentication, 

Access Control Lists (ACLs), Secure Socket Layer (SSL) support and 

RSA-based public key encryption of data. These capabilities permit secure 

connections to Web servers running SSL and also protect communications 

between the webMethods B2B Server and your trading partners. 

Netfish XDI server 

Netfish XDI Server enables routing of outbound requests through an 

SSL proxy server. Inbound requests can also enforce either server-side 

SSL authentication or mutual (server and client) SSL authentication 

(see Figure 10.18). The XDI Server supports importing digital certificates 

in standard formats such as PKCS#12 and PKCS#7 and allows trading 

partners to use distinct certificates for data encryption and signing. 

TIBCO TIB/BusinessConnect 

Tibco's B2B solution — TIB/BusinessConnect supports 56- and 128-bit 

SSL encryption. For authentication, it utilizes digital signatures, X.509


N 

XDI Web 

Server Server 

DMZ 

HTTPS 

XDI Web 

Secure Server 

Gateway HTTPS 

Figure 10.18. — Netfish XDI server 

Internet 

Trading 

Partner 

certificates and Public Key Infrastructure (PKI). It provides automated 

sub-processes for the signature and encryption of business documents, 

as well as for verification and decryption. 

10.8.4. E-security tailored to XML 

XML is fast becoming the lingua franca of e-business. All through the 

industry, companies are using XML at the interface of their systems to 

exchange a variety of data and documents. XML documents are 

comprised of data and metadata, i.e., information describing the meaning 

of the data. It is becoming a key requirement of integrated systems to 

process or parse this data efficiently. Hence, companies are welcoming 

security algorithms tailored to XML. 

XML Security Suite is one such product, by IBM AlphaWorks. It 

pushes the security further by introducing new security features, such as 

digital signature, element-wise encryption and access, control that are 

beyond the capability of the transport-level security protocol such as 

SSL. Element-wise encryption means that one can choose the specific 

elements of an XML document which one wants to secure. 

At the time of writing, the release of XML Security Suite provided 

reference implementations of DOMHASH, a proposed canonicalized 

digest value for XML documents. DOMHASH may be a basis for XML 

digital signature that is being discussed in both IETF and W3C. The 

IETF and W3C have combined their efforts and are working towards an 

XML signature specification. The XML signature syntax will express 

the relationships between cryptographic signatures and Web resources


(anything that can be referenced by a URL). It will also include the 

procedures for processing and verifying XML signatures. 

Another advancement is Security Services Markup Language (S2ML), 

which is under development by Netegrity, VeriSign and several other 

e-commerce vendors. S2ML provides a standard way of defining user 

authentication, authorization, entitlement and profile information in XML 

documents, thus allowing business users to move from site-to-site without 

multiple sign-ons. 

10.9. Secure Payments Over the Internet 

B2B e-payment and settlement is complex and requires coordination 

among multiple parties. For a single B2B payment, documents may be 

exchanged among the buyer, the seller, marketplace, shippers, insurers, 

financiers, regulators and other parties. It is not easy to automate a 

payment that involves so many parties. In order to automate the complete 

process, right from purchase of the order to the final exchange of 

payment between the parties, cooperation is required from banks, 

technology providers and the member companies of the marketplaces. 

As transactions happen over the Internet, a need for electronic 

payment systems for handling the payment part of the transaction 

arises. B2B payment systems must securely handle: 

• Financing; 

• Electronic funds transfer; 

• Payment; 

• Invoicing; 

• Reconciliation; 

• Online contracting; and 

• Authentication. 

In a typical dynamic B2B scenario, transacting companies would be 

assigned crypto-secured digital identities that would be validated in 

real-time. However, these digital identities, by themselves are not good 

enough to provide the right business conditions, such as security, 

reliability and trustworthiness for online B2B transactions. Without the 

involvement of an external entity that interacts with parties at both ends


and maintains a comparable mode of verification of each party's consent, 

B2B transactions cannot be enforced. 

10.9.1. Need for trusted third party entities 

In B2B e-commerce transactions, which can run into millions of dollars 

without ever involving a piece of paper, companies cannot trust new 

business partners simply on the basis of an e-mail address or a password 

or a Website address. There is a need for the involvement of a financial 

institution that can validate and facilitate all the financial aspects of a 

transaction. Their involvement will give participating companies the 

assurance they require to conduct negotiations, reach agreements and 

make payments in a trusted and secure manner. 

The trusted third party entity should: 

• Issue digital certificates; 

• Provide guarantee of these digital certificates; 

• Have a global presence and a large clientele; 

• Support open standards and provide technology interoperability, so 

that the participant companies can use security solutions that best fit 

their needs; 

• Provide transactional integrity and assurance that can bind all the 

participants to contracts that are enforceable across all countries; and 

• Maintain the audit information in the form of electronic paperwork to 

trace back any transactions or communications. This audit can be 

used to resolve any dispute between two parties using their services. 

Without the audit information, which is a comparable mode of 

verification of the concerned party's consent, it will be difficult to 

enforce an electronic transaction. 

Identrus is a typical example of such a trusted third party entity, 

which brings together several leading financial institutions (FIs). The 

partner FIs issue guaranteed digital certificates that enable their customers 

to participate in B2B e-commerce. In addition, FIs also act as payment 

intermediaries and offer their traditional financial services securely over 

the Internet. 

As an example of a transaction through Identrus Network (see 

Figure 10.19), a manufacturer receives a request for a proposal over

Bank 1 

Certif i cate 

Validation 

Prospective 

Trading Partner 

Identrus, 

LLC 

Real-Time 

Certificate/Identity 

and Credit Verification 

RFP 

Response 


Certif i cate 

Validation 

Bank 2 

Manufacturer 

Figure 10.19. — Example of a transaction in identrus network 

the Internet from an unfamiliar source. Without confirmation of the 

company's identity, it may make little sense today to set aside inventory or 

even consider the bid, because the manufacturer would have to engage in 

extensive diligence. As a customer of a financial institution participating 

in Identrus, the company could present a compliant digital certificate along 

with the Request for Proposal (RFP). The manufacturer could then fully 

trust in the identity of the originator of the RFP. If the RFP came with 

credit information verified by a participating financial institution's digital 

certificate, the manufacturer could rely on that information to determine 

the credit-worthiness of its prospective trading partner. 

10.10. Security Trends for the Future 

A few security trends for the future are: 

• The need to control and secure digital content will grow tremendously. 

Boston-based consultancy Yankee Group predicts that a market for 

secure content delivery technologies will evolve, exceeding US$200 

million in 2001 and US$2 billion by 2005.


• The Yankee Group predicts that the market for network and computer 

security will reach more than $10 billion by 2003, up from $2.3 

billion in 1998. 

• By 2005, the managed security service provider market will grow to 

over US$2.6 billion. Managed service providers (MSP) will try to 

integrate the needs of e-commerce, Web hosting, IP virtual private 

networks (VPNs) and managed security services. 

ESTABLISHING ELECTRONIC COMMERCE VIA 

CERTIFICATE AUTHORITIES 

Security Considerations for OASIS Electric Utility Websites 

OASIS (open access, same-time, information systems) is a project 

that facilitates transactions of wholesale electricity to utilities and 

corporate customers nationwide. OASIS was designed by the Joint 

Transmission Services Information Network (JTSIN), a consortium 

of regional electric utility cooperatives. 

OASIS emerged when the Federal Energy Regulatory Commission 

(FERC) mandated that wholesale buyers, sellers and distributors of 

electric power have equal access to information about power transmission, 

availability and pricing. Previously, wholesalers and corporate 

customers used to rely on personal contacts to find electricity at 

bargain prices; now all information on pricing and available power 

grid capacity is open to them via the Internet through the secure 

VPNs created by OASIS. 

JTSIN outsourced project development to BSG, Cegelec ESCA 

Corp., with TradeWave Corporation as the developer of the system's 

security architecture. 

OASIS went online in January 1997 and consists of over 500 

separate entities and market makers in the electric power industry, 

trading an estimated $35 billion in transmission capacity, making it 

one of the largest e-commerce projects (see Figure 10.20). 

Information surrounding the availability and pricing of electricity, 

like that of any commodity, must remain confidential. A system that 




- &jer 500 separate entities and 

market makers in power industry 

- Trading an estimated $35 billion+ in 

electric pow er transmission capacity 

Figure 10.20. — OASIS consists of over 500 separate entities and market 

makers in the electric power industry, trading an estimated $35 billion in 

transmission capacity 

generates multi-million dollar transactions demands both dataencryption 

and user-authentication capability. Security has to be strong 

enough to guarantee the integrity of the billing and payments that 

will soon be transferred onto OASIS. OASIS sites that have implemented 

TradeWave's TradeVPI (Virtual Private Internet) solution 

have overcome each of the security concerns that previously stunted 

the development of e-commerce on the Web. 

Security concerns that OASIS participants face include effective 

authorization mechanism that controls users' access to the VPN, as 

well as control over what information users can view, based on their 

level of trust. Mutual authentication is needed to verify both those 

sending and those receiving information. Strong encryption is needed, 

along with tools that ensure that messages are not altered in any 




way. Once a message is sent, non-repudiation capability must be in 

place so that there is no question who sent or received a particular 

message. 

TradeWave secured OASIS transactions by building upon an Entrustbased 

Public Key Infrastructure (PKI) to create a nonproprietary, 

open-architecture solution that meets all relevant industry, government 

and international security standards. The standard Entrust PKI was 

advanced by 'Web-enabling' it, automating its ability to issue certificates 

and adding an access-control tool that handles data-access 

privileges for each user. 

Security Implementation at MAIN 

The major TradeVPI components that support the OASIS architecture 

at JTSIN participant MAIN (Mid-America Interconnected Network) 

are the TradeWave's online certificate authority (CA) service, client 

and server software and the TradeAccess Control Server software. 

• A trusted CA directory manages and distributes electronic keys for 

encrypting information and electronic certificates for authenticating 

user and server identities. 

• TradeAgent client enables a user's Web browser to gain secure 

access to the Web pages of MAIN and other participating OASIS 

utilities. 

• TradeAgent Server provides secure MAIN resources, such as 

confidential OASIS pages, to TradeAgent client users. 

• Both the TradeWave client and server software encrypt and decrypt 

data detailing the pricing and availability of electricity at MAIN 

and other OASIS participants. 

• The TradeAccess Control Server software ensures that authenticated 

users with the proper access privileges can access certain protected 

MAIN and OASIS resources. 

User Authentication 

Users must first be approved by a local registration agent (LRA), who 

provides the user with a security profile. MAIN'S LRA then confirms 




the approved registrant with TradeAuthority, the IBM-supported CA 

server protected at a physically secured site in Austin, Texas. 

As an example, a broker in Pennsylvania who wants to log onto 

the VPN of Wisconsin-based MAIN to check pricing and availability 

of electricity must first be confirmed by TradeAuthority, which matches 

a user's encrypted log-on signature with the signature included in the 

stored profile. 

Once the broker's log-on is validated, this potential customer has 

access to any OASIS node without having to log on again, avoiding 

the inconvenience of having to remember separate IDs and passwords 

for each JTSIN account. 

To access MAIN Web documents, the customer enters the desired 

MAIN URL and forwards this request through TradeAgent client. 

TradeAgent client then contacts the CA to obtain the certificate for 

the desired MAIN address. It opens contact with MAIN'S TradeAgent 

server. TradeAgent client and server can now authenticate each other 

by checking a certificate revocation list for both the client and server; 

if neither the broker's address nor MAIN URL is on the revocation 

list, communication between the two may proceed. 

The session continues with client and server selecting a public 

key to encrypt data traveling between them, as well as algorithms 

that ensure data confidentiality and integrity. 

Access Control 

Each user in the OASIS system has specified access privileges as 

deemed appropriate by the administrator. 

With TradeVPI, MAIN has a system in place that is secure 

enough to meet the expected explosion in electronic commerce. 

Billing information will soon be shared with other providers and 

utilities. Transaction payments aren't far behind. The present architecture 

gives ITSIN the security to easily migrate billing and payments 

to the Internet. 

The OASIS system addresses security concerns with an infrastructure 

in place that not only protects the proprietary information 

of its corporate members, but also has the encryption and 




authentication capability that can process purchases of electrical 

power worth millions of dollars. OASIS is a blueprint for commercial, 

public-key infrastructure-based electronic commerce. 

Source: Condensed from cyberguard-ecom.se-com.com white paper 


B2Bi involves significant security risks, as it involves the use of the 

Internet for conducting business. Anonymity, a key characteristic of 

B2B e-commerce, also adds a lot to the uncertainty of online B2B 

transactions. Security breaches in this environment can cause severe 

losses and damages to the reputation of the parties involved. For example, 

a security hack, such as denial-of-service (DOS — incapacitating 

Web servers by flooding them with nuisance traffic) attacks on any 

major B2B exchange can virtually cripple the whole industry and lead 

to millions and millions of real dollar losses to corporations, apart from 

destroying the credibility of the company running that exchange. As a 

matter of fact, the economic damage caused by e-security breaches, 

such as hacker attacks, viruses, denial of service attacks and unauthorized 

access, exceeds $15 billion annually. 

E-security in lieu of B2Bi is not just using a secure connection 

provided by SSL or placing a corporate firewall in place. It requires a 

whole revamping of enterprise-wide security policies and solutions. The 

revamped security solution has to help companies better leverage their 

existing infrastructure, be cost-effective and reduce security breach 

risks with each dollar spent. 

Organizations that offer all the financial services over the Internet 

and provide both the technological and operational infrastructure for 

secured B2B transactions will thrive in the future.

Part III 

Evolving Integration 

Components 

323


Chapter "| 1 

Web Services 


Web services based on service-oriented architecture are an evolution in 

e-business applications that will help companies reach their integration 

goals and take B2B to the next level. 

In this chapter, we present the latest technology being developed 

in the B2B integration domain — Web services. You will learn about 

SOA, UDDI, WFSL, WSDL and how they fit into the architecture of 

Web services. 

325


11.1. Service Oriented Architecture (SOA) 

We have discussed in the previous chapters that B2Bi involves dynamic 

integration of heterogeneous applications and platforms across multiple 

organizations. A minor alteration in just one of the applications, at one 

of the firms, can break the whole integration. 

For true dynamic integration, software resources such as applications, 

objects and programs should be loosely coupled. These resources should 

make their presence known to the world and provide public interfaces, 

which describe their actions. The communication between these resources 

and the applications using them should occur, based on open standards. 

Using these resources, which can be personalized for each user, the 

future applications would be built dynamically within seconds. 

This is where SOA comes into the picture. It provides a framework 

and architecture for interconnecting applications and software components 

seamlessly. It provides the ability to invoke remote business services 

and install them as local components in a different application, all without 

writing a single line of low-level code. 

11.1.1. Components and operations of SOA 

There are three components of service oriented architecture (see 

Figure 11.1). They are: 

• Service Provider — This component is responsible for creating and 

publishing the interfaces of services, providing the actual implementation 

of these services and responding to any requests for the 

use thereof. Any company or business can be a service provider. 

• Service Broker — This component registers and categorizes public 

services published by various service providers and offers services 

like search, etc. Service brokers act like a repository or yellow pages 

for Web services. Companies that want to use Web services can 

search these yellow pages to find one matching their needs. Currently 

several companies including Ariba, IBM and Microsoft are acting as 

service brokers. 

• Service Requester — This component is the actual user of Web 

services. Service requesters discover Web services by searching the 

repository maintained by the service brokers and then invoke these

Service 

Provider 

PublishJF ^k Bind 

c&rui*"-^ Service i 

5JJJU |^WBM»«MB^ Rec|uester ! 

Find 

Figure 11.1. — SOA model 

Web Services 327 

services by communicating with the actual service providers. In most 

cases the invocation would be remote over the Internet, but it is also 

possible that the invocation of the service is local over the intranet, 

which means that the requesting company is also the service provider. 

The three most basic operations through which the SOA participants 

interact are: 

• Publish — It allows the service provider to publish its services and 

interface requirements with a service broker. WSDL (Web services 

description language) is an XML-based language used to perform the 

operation of describing the interface of Web services which are then 

published using UDDI. 

• Find — This operation allows a service requestor to locate, search 

and discover the services published via a service broker that are 

offered in a particular classification or by a specific service provider. 

Finding is enabled by the UDDI (Universal description, discovery 

and integration) framework. 

• Bind — This operation enables a service requestor to actually bind 

and use a service provided by a service provider. Binding is enabled 

by SOAP-based XML messages. 

11.2. What are Web Services? 

Web services are URL-addressable, self-contained resources and/or 

applications that can be described, published, located and invoked over 

a network, usually the Internet. Web services are XML representations 

;


of applications, resources, messages and objects that enable applicationto-application 

interaction over the Internet. They provide well-defined 

interfaces, called contracts, that describe the services provided. Web 

services are based on service oriented architecture (SOA) and support 

bind, publish and find operations. Each component (network node) can 

play any or all roles of a service broker, service requester or service 

provider. 

Web services enable companies to publish public interfaces of their 

business objects and programs so that other companies can search and 

find them and interact with these services. 

At the core of Web services is the fact that each service encapsulates 

the implementation details and publishes a messaging API, so that it 

can be used by other services over the network. Web services have 

all features of object-oriented systems, such as encapsulation, message 

passing, dynamic binding and service description and querying. Through 

the dynamic binding of components, which is platform and programming 

language-neutral and communications mechanism-independent, they 

enable just-in-time integration of applications. 

Web services enable full leverage of existing infrastructure and 

applications. The existing Web applications (Internet/Intranet) can be 

easily converted into Web services, irrespective of the platform or 

programming language used to implement these applications. The Gartner 

Group predicts that by 2004, 40% of legacy enterprise applications will 

be partially or fully service oriented. 

Examples of practical use of Web services in the B2B world include: 

• A company invoking another company's service to send a purchase 

order (PO) over the Internet; and 

• A logistics company writing a service which calculates the cost of 

shipping goods based on weight, delivery date, etc. that other companies 

can use to figure out the cost, based on their shipment details. 

11.2.1. Application of SOA-based framework to B2Bi 

The requirements: For B2Bi, companies have to use a framework that 

provides high-performance, reliable, extensible, scalable, secured and 

open standards based communication and messaging.


The solution: A SOA-based framework can enable companies in 

achieving their B2Bi goals by providing a service-based platform to 

integrate new and existing applications and systems, implementing 

industry standards, and building an infrastructure that would support the 

dynamic messaging required for continuous processing for all types of 

business transactions. Service-oriented architecture can provide the 

foundation and Web services can provide the building blocks for 

application architecture in order to achieve seamless trade processing. 

A SOA-based framework is capable of providing support for multiple 

XML standards, such as ISO15022, cXML, and FpML, at the same time, 

and adding additional standards support without significant redevelopment 

effort. With the use of Web services as an enabling technology, B2Bi 

related problems and issues will shift from connectivity among different 

applications in-house and with trading partner applications to the content 

and structure of the information that is exchanged. The analogy here 

will be that Web services will define the standard postal mechanism 

along with the envelope and addressing format for exchanging letters. 

What is inside the envelope (the content of the letter) will be defined 

by the XML-based business process standard, such as ISO 15022 XML 

or RosettaNet. 


Environment 

There are several essential features for the operation of Web services. 

The Web services environment provides a framework that gives the 

ability to dynamically discover, install and re-use business services. 

A Web service needs to be: 

• Created and its interfaces and invocation methods must be defined; 

• Published to one or more intranet or Internet repositories for potential 

users to locate; 

• Located to be invoked by potential users; 

• Invoked by other Web services, applications; 

• Provide access to standard library functions such as security, search, 

translation, logging and transactions;


• Unpublished when it is no longer available or needed; and 

• Integrated with other Web services using Internet standards. 

As discussed, Web services involve exchange of XML messages. 

It is mandatory for Web services to associate XML schemas (which 

define the data types, requirements of XML documents used for 

messages, types of messages and operations the messages are mapped 

to) with these XML messages. Web services can be implemented in any 

language (such as C, Java and C++) using any technology such as EJB 

and CORBA, as long as they are able to generate and parse XML 

documents. 

11.4. Universal Description, Discovery and 

Integration (UDDI) 

Although it may seem relatively easy to discover the Web services of 

known trading partners, it is not easy to know all services and how they 

work. Again, if a company is involved in dynamic business trading, 

how would it know the Web services offered by new partners? How 

will it ensure that the information that it has about a service is up-todate? 

Thus, there is need for a mechanism which provides real-time 

information about services, ensures consistency in service description 

formats and makes it easy to track the changes as they occur. There is 

a need for a solution that maintains distributed directories/registries 

of businesses and their services in a common language and format 

understood by all. That solution is UDDI — a primary resource for 

identifying and connecting with potential collaborative partners using 

Web services. 

11.4.1. What is UDDI? 

UDDI is a centralized business registry that enables business-to-business 

communication. UDDI is a standard way of addressing the need for a 

repository or broker that will manage a directory of service interfaces. 

IBM, Microsoft and Ariba outlined their specification to help facilitate 

the creation, description, discovery and integration of Web-based services.

A UDDI registry basically has two types of users: 


• Businesses that publish a service and its XML-based usage interface; 

and 

• The clients that want to use these services by binding to them. All 

companies that register in the UDDI business registry are assigned a 

globally unique identifier. 

11.4.2. UDDI built on SOAP 

As discussed in the previous chapter, SOAP enables information in the 

form of XML documents to be exchanged across system boundaries. 

UDDI is actually built on top of SOAP, i.e., the UDDI APIs are built on 

SOAP specifications. As depicted in Figure 11.2, UDDI uses technologies 

such as TCP/IP, XML and SOAP to create a uniform service description 

format and service discovery protocol. All UDDI documents are actually 

SOAP-based XML documents. 

It is worth mentioning that although the UDDI API is implemented 

using SOAP, there is no requirement that the services registered in 

UDDI use SOAP. 

llnivPinfil>M> Maikup Lnnquaqr (XML) 

Common Internet Protocols (HTTP, TCP/IP) 

Figure 11.2. — UDDI built on top of SOAP 

11.4.3. UDDI data structure 

The core information model used by UDDI registries is defined in 

an XML schema (http://www.uddi.com/schema/uddi_l.xsd), which


defines business information, service information, binding information 

and information about specifications for services. The basic organization 

of the UDDI data structures is as follows (see Figure 11.3): 

Business Entity — (top level structure that describes a business) 

-Business Service — (describes a service and groups a series of 

related Web services related either to a 

category of services business process or a 

category of servicesuch as purchasing and 

security) 

-Binding Template —> points to a tModel (contains the information 

required to 

actually invoke this 

service) 

-Binding Template —> points to a tModel 

-other Binding Templates ... 

-other Business Services ... 

-Binding Templates ... 

tModels is a list of references that provide the access information, 

i.e., metadata about Web services. Each binding element contains this 

element. There is an m:n (many-to-many) relationship between business 

services and tModels. 

 

-name 

-description 

-URL pointers to specifications 

Since each business entity, business service and tModel can be 

associated with single or multiple categories and identifiers, UDDI 

supports precise search based on these categories and identifiers.

usinessEntity: Information about the 

party vho publishes information about a 

service 

! 

I j businessService: Descriptive 

WimsmW i nf orm atio n a bo ut a pa |-ti ou la r 

family of technical services 

Source: uddi.org 

""-"> bind ngTempi ate: Technical 

I information about a service entry 

point and construction specilcations 

ff 

Figure 11.3. — UDDI data structure 


', tModel: Descriptions of specifications , 

fo r se rvices o f taxon om i es. Ba sis for 

teehn ica I fi n gerp rints 

bindingTemplate data contains references 

totModels. These references designate the 

interface spedficationsfor a service. 

Note: Please refer to Appendix B for UDDI Information Model. 

11.4.4. UDDI APIs 

UDDI supports two types of APIs that allow users to publish and access 

Web services maintained in the UDDI registry. 

• Inquiry API — As the name itself indicates, inquiry API allows 

users to inquire and locate a business, Web service and its 

specifications. It is also used in situations where Web service 

invocations experience failures. 

• Publishers' API — This API enables the companies to publish 

information about business entities, services and tModels into a 

UDDI registry. 

11.5. Web Services Description Language (WSDL) 

WSDL is an XML language that describes a Web service, specifies its 

location, describes the operations (i.e., methods) it exposes, defines the 

XML messages it generates and exchanges and its binding details. 

WSDL is a format for describing networked XML services in terms of 

'endpoints', which are a way to request XML-related functionality from 

a remote machine over a network such as the Internet. It standardizes


the format of publishing the operations of a service with their respective 

parameters and data types, defining the location and binding details of 

the service. 

WSDL syntax enables both the messages and the operations on the 

messages to be defined abstractly, so that they can be mapped to 

multiple physical implementations, such as SOAP, HTTP and MIME. 

WSDL is independent of the underlying protocol and encoding 

requirements, thereby enabling dynamic cross-platform integration. 

11.5.1. WSDL schema 

A WSDL XML schema (as defined by IBM and Microsoft) includes the 

following parts: 

• Types — a container for the different data types contained in the 

message, which can be in the form of XML schemas or some type 

system (such as XSD); 

• Message — an abstract description of the data being exchanged that 

can be presented as full documents or as arguments mapped to an 

operation invocation; 

• Operation — an abstract definition of an action (such as a business 

process) supported by a Web service; 

• Port Type — an abstract collection of operations that are mapped to 

one or more endpoints, which enables the operations to map to one 

or more transport protocols; 

• Binding — used to attach a concrete protocol and data format 

specification for a port type; 

• Port — an endpoint defined as a combination of binding a 

network address, which provides the target address of the service 

communication; and 

• Service — a collection of related endpoints that map the binding to 

the port and include any extensibility definition. 

11.5.2. WSDL and UDDI 

WSDL complements the UDDI standard by providing a uniform way of 

describing the interface and protocol bindings of network services.


According to the technical specifications made available by IBM and 

Microsoft, UDDI-based Web services can be created using WSDL by 

the following steps: 

1. Create the WSDL service interface definition. Typically, industry 

groups will define a set of service types and describe them with one 

or more service interface definition WSDL documents. The service 

interface definition will include service interfaces and protocol 

bindings and will be made publicly available. The WSDL service 

interface definitions are then registered as UDDI tModels; the 

overviewDoc field in each new tModel will point to the corresponding 

WSDL document. 

2. Build services that conform to the industry standard service definitions. 

To do so, retrieve the tModel description of the industry standard 

definition and (following the overviewDoc link) obtain the 

corresponding WSDL definition document. 

3. Deploy and register the new service in the UDDI repository. To do 

so, create a UDDI businessService data structure and then register it. 

11.6. Web Services Flow Language (WSFL) 

The Web Services Flow Language (WSFL) is an XML language for the 

description of Web services compositions. It provides the ability to 

compose Web services together, describe business processes, create 

workflows and describe overall interactions between varying Web 

services with no specified sequence. It provides a specification for 

implementing business process models, using Web services architecture, 

and is used for creating XML-based representation of business models. 

WSFL is layered on top of the WSDL. WSDL describes Web 

services endpoints where individual business operations can be accessed, 

whereas WSFL uses WSDL for the description of service interfaces and 

their protocol bindings. 

11.7. Putting Everything Together 

After having discussed all the components of Web services, let's try to 

redefine them. A Web service is a modular application that can be:


Figure 11.4. — Example of Web Services in B2B applications 

Supplier C 

• Described using WSDL; 

• Published using UDDI; 

• Found using UDDI; 

• Bound using SOAP (or HTTP GET /POST); 

• Invoked using SOAP (or HTTP GET/POST); and 

• Composed with other services into new services using WSFL. 

Figure 11.4 shows an example of actual use of Web services in a 

B2B application, where a buyer gets information about Web services of 

suppliers using private UDDI registry and invokes these services over 

the Internet to get quotes for a specific item. 


Framework 

A Web services framework for EAI and B2Bi has to provide an 

integrated development environment and platform for easily building 

and deploying Web Services and service components. There are a few 

essential features that Web Services solution vendors will have to 

incorporate in order to successfully support Web Services, without 

which their use and adoption within companies is not possible. They 

are (see Figure 11.5): 

• Easy and secured connectivity to private and public UDDI, or any 

other repository;

Connectivity to 

Public and Private UDDI 

Reliable Messaging Strong Security 

Built-in Transaction 

Registry Management 


Features of 

Web Services T „ .. ... 

Scalable Solution Integration with 

Execution Existing Infrastructure 

Environment (such as J2EE Servers, 

Integration Brokers) 

Failover Capability 

and Load Balancing 

Administrative Development, 

Tool Deployment 

and Publishing Tool 

Integration with 


Figure 11.5. — Features of Web Services solution 

• Effective audit mechanism, through which the access and usage of 

Web Services can be closely monitored; 

• Efficient security safeguards, such as policy management and 

authentication, for the access and usage of Web Services; 

• Easy development, deployment, publishing, finding and dynamic 

binding for Web Services interfaces; 

• A stable environment for rapid development of Web Services-based 

applications; and 

• Workflow management and personalization. 

11.9. Security Requirements for Web Services 

No matter how big a company is or what it does, security will be 

the primary consideration when choosing a Web service for all B2B 

applications. The key security requirements for the usage of Web services 

are authentication, authorization, data protection, and non-repudiation.


11.9.1. Authentication 

Authentication is a security requirement that ensures each entity involved 

in the usage of a Web service — the requester, the provider, and the 

broker (if there is one) — is what it actually claims to be. Authentication 

involves accepting credentials from the entity and validating them 

against an authority. While Web services for EAI should have one level 

of authentication and rarely make use of encryption, Web services for 

B2Bi may involve multiple levels of authentication and should always 

use encryption. Of course, there will always be a tradeoff between 

robust security and performance. 

11.9.2. Authorization 

Authorization is a security requirement that determines whether the 

requestor has been granted access to the Web service by the service 

provider. Basically, authorization confirms the service requestor's 

credentials — checks that the service requestor is entitled to perform 

the operation, which may range from invoking the Web service to 

executing a certain part of its functionality. 

11.9.3. Data protection 

Data protection is a security requirement that ensures that the Web 

service request and response have not been tampered with en route. 

Data protection requires securing both data integrity and privacy. It is 

worth mentioning that data protection does not guarantee the identity 

of the message sender. In the case of B2Bi projects, the messages 

corresponding to Web service request and response should always be 

encrypted, using one or more of the following: cryptography, digital 

signatures, secured socket layer (SSL), and so on. The use of SSL 

should be avoided, as far as possible, for Web services used within the 

corporate network for EAI projects. 

11.9.4. Non-repudiation 

Non-repudiation guarantees that the sender of a message is the same as 

the creator of the message. This is very useful for Web services used in


the B2Bi domain, as otherwise a malicious sender can later disavow 

having created and sent a specific message. 

The importance of each one of these requirements is determined on 

an application-to-application basis and factors such as whether the Web 

Service is being used for EAI or B2Bi, what's the level of access that 

the Web service provides to the underlying and should the access be 

based authorization and entitlements. But, one thing is for sure — 

security is one of the primary factors that would determine the adoption 

of Web Services by companies of all sizes and in all sectors. 

11.10. Where to Start? 

Companies should start using Web services in internal application 

integration projects on a function, application programming interface 

(API) or remote procedure call (RPC) level. This will orient the IT staff 

with the technology issues involved in using Web services, which 

would be very helpful in overcoming the challenges later posed when 

the company uses Web services for external application integration 

(B2B integration) projects. It is much easier to control, manage, find, 

execute and maintain Web services within an intranet, as compared to 

using them over the Internet across the corporate firewall. Furthermore, 

it would help companies in identifying business opportunities using 

standardized and relatively cheap Web services solutions as opposed to 

expensive EAI broker solutions. 

Web services will gradually evolve from an EAI solution to a B2Bi 

solution over a period of time. 

11.10.1. Leverage existing assets 

It would be utterly naive of companies to scrap the existing EAI 

infrastructure and blindly march towards deploying Web Services to 

replace it. Companies cannot stop using the EAI middleware frameworks, 

which provide full transactional services, in lieu of Web Services, 

which don't (as yet). Instead, they should use Web Services to leverage 

existing infrastructure. 

Using Web Services, companies will also be able to leverage the 

resources they have invested in implementing any .NET and/or J2EE


projects. Web Services technology works hand-in-hand in .NET and 

J2EE technologies, rather than as a competing technology. For instance, 

J2EE connectors give developers an interface for accessing legacy 

transactions and data, whereas Web services provide a uniform, standardsbased 

technique for exposing application functionality over the Internet 

or the corporate intranet. 

11.10.2. Build an internal repository for Web Services 

Early on in their adoption of Web Services, companies should make an 

effort to develop an internal centralized service repository for publishing 

information that internal applications can use to find information about 

published Web Services. If each group and department starts maintaining 

their own repository, over time there will be several repositories within 

the company, making the publishing, discovery and use of Web Services 

a painful and time consuming process. 

11.10.3. Bottom line 

Web Services, by themselves, are not the nirvana for EAI or B2Bi. An 

EAI and/or B2Bi platform within a Fortune 500 company would still 

comprise multiple solutions which together would offer both non-real 

time and real-time integration, support for managing semantic 

transformations, business process integration and application integration, 

based on open standards and proprietary formats. 

11.11. Web Services Networks 

The use of Web services for B2Bi will be enabled through the emergence 

of trusted managers, known as Web services networks. Web services 

networks will be built on open Internet standards, including Web services. 

They will take on the responsibility for managing the security, transaction 

management, versioning, publishing, finding and deploying Web services. 

They will help in overcoming the biggest hurdle of using third party Web 

services for B2Bi — the inherent unreliability of unqualified sources. 

Grand Central Network is an example of such a Web services oriented 

network.


It is worth mentioning, though, that over time there will be too many 

of such networks and companies will have to make diligent choices 

about joining them. Most of these networks will meet the same fate as 

several e-marketplaces, which sprung up all over and gradually started 

to disappear. 


The Web services architecture enables the creation of dynamic and 

loosely coupled applications, based on the public services that companies 

expose. It provides a data independent, platform neutral, programming 

language independent and a communication protocol independent 

technology that reveals business services on the Internet, using standard 

XML protocols and formats. 

Instead of the conventional static binding, since Web services allow 

dynamic binding of applications, its architecture will be of enormous 

relevance to several B2B applications like product collaboration, shared 

business processes applications and value chains. 

The Universal Description, Discovery and Integration (UDDI) 

framework allows companies to search and discover Web services 

based on categories such as industry classification and business function 

or type of service. 

Several companies such as IBM, Ariba, Microsoft, Sun Microsystems 

and Hewlett Packard are betting on the Web services development 

paradigm.

Chapter "] 2 

Wireless Technologies 


Wireless technology will play a crucial role in B2B interactions and 

transactions. Mobile e-commerce is still evolving rapidly while ecommerce 

has reached a more mature stage. Global mobile e-commerce 

is projected to have revenues of $200 billion by 2004, with 130 million 

customers and 14 billion transactions annually. 

In this chapter, we present the benefits of mobile commerce, wireless 

application architecture and components including Wireless Access 

Protocol (WAP), Wireless Markup Language (WML) and WMLScript. 

You will also learn about the security issues involved in wireless 

applications, examples of wireless B2B applications and integration of 

these applications with the B2Bi infrastructure. 

342


Wireless Technologies 343 

Business-to-business (B2B), business-to-consumer (B2C) and businessto-employee 

(B2E) have all involved wired interactions over telephone, 

fax, local area network (LAN), Internet and intranet among entities and 

individuals. Exceptions have been those rare field workers, such as UPS 

deliverymen and the field employees of progressive companies, who 

have employed wireless technologies. 

E-commerce involves wired transactions through Websites and can 

involve either businesses or individuals that take part in transactions 

with other businesses. In contrast, mobile e-commerce (m-commerce) 

involves the same types of entities, but the transactions are performed 

wirelessly. M-commerce is still evolving rapidly while e-commerce has 

reached a more mature stage. Table 12.1 outlines the salient technical 

differences between e-commerce and m-commerce. In terms of devices, 

content delivery standards and bearer networks, m-commerce is far 

more complex than e-commerce. The purpose of this chapter is to 

examine wireless technologies in the context of B2Bi. 

Table 12.1. E-commerce and m-commerce — Technical components 

Components 

Devices 

Operating System 

Content Delivery 

Standards 

Browsers 

Bearer Networks 

PC 

E-commerce 

Windows, Unix, Linux 

HTML 

MS Explorer, Netscape 

Navigator 

TCP/IP 

M-commerce 

Smartphones (low and high 

end), PDAs, pagers 

EPOC, PocketPC, Palm 

HTML, WML, HDML, cHTML 

Phone.com's UP, Nokia 

GSM, CDMA, TDMA, CDPD, 

paging networks


12.2. The Wireless Internet Today 

Let us take a look at the wireless Internet as it stands today. 

12.2.1. Definition and growth 

The phrase 'Mobile Internet' conjures up images of an individual with 

the ability to get whatever information desired, wherever and whenever 

needed and on virtually any device — tethered or untethered. The 

reality is that we are not quite at that point yet. The extant wireless or 

mobile Internet is in an evolutionary phase akin to the one the traditional 

Web entered in the mid 1990s. At that time there were only a limited 

number of online services that were available to users. A salient 

difference between the wired (i.e., tethered) and unwired (i.e., untethered) 

or mobile Web is that there is no longer serious doubt as to whether 

select consumers and companies will want to use the Web to purchase 

goods and services from their desk or while on the run. People want to 

take their technology with them and thus the potential for the mobile 

Internet has already gained a wide and growing acceptance. 

Mobile e-commerce or m-commerce, as it is sometimes termed, 

involves the use of mobile handheld devices, such as mobile phones, 

personal digital assistants (PDAs) and two-way pagers to communicate, 

interact and transact. The purpose of these handheld devices is to use 

wireless technologies to provide convenient, personalized and locationbased 

services to customers, employees, partners and ordinary people. 

There is no doubt that the m-commerce market has the potential to 

explode. Wireless subscribers have been projected to grow from 

400 million in 1999 to over 1 billion in 2003. This means that in the 

near future, approximately 1 in 6 people on earth will have access to a 

cell phone. Wireless Internet subscribers have been projected to grow 

from 6 million in 1999 to over 400 million in 2003. For most people, 

the wireless Internet may be the only Internet that they use on a regular 

basis. Global m-commerce is projected to have revenues of $200 billion 

by 2004, with 130 million customers and 14 billion transactions annually. 

Table 12.2 outlines commonly cited wireless Internet projections. 

Since these projections were made at an initial stage, the technology 

sector has imploded, particularly in the United States. However,


Table 12.2. U.S. wireless internet access device projections (in millions) 

Device 

High-end smartphones 

Low-end smartphones 

Net-capable PDAs 

Alpha-numeric pagers 

E-books 

1999 

0.3 

0.8 

5.2 

2.4 

0.0 

2000 

0.8 

5.3 

6.9 

3.5 

0.6 

2001 

1.6 

27.7 

8.6 

4.7 

1.3 

2002 

2.4 

57.5 

10.3 

5.9 

2.1 

2003 

technological progress has continued and will continue to be inexorable. 

When economic fortunes change for the better, people will still want to 

take their technology with them. This bodes well for wireless. 

12.2.2. Mobile benefits 

It is conceivable that m-commerce will expand across several industries 

initially: transportation and travel — automotive and air travel; financial 

services — retail banking, brokering and the use of mobile 'wallets'; 

media and entertainment — newspapers, music, video and gaming. 

Mobile offerings will undoubtedly evolve with technology and as dictated 

by the desires of early adopters. 

For example, in 1999, one could get news through personal instant 

messaging (PIM) and short message services (SMS). In 2000, this 

evolved to what might be termed communication enhancements: e-mail, 

instant messaging (IM), wireless application protocol (WAP) alerts and 

the provision of directories wirelessly. At present, the floodgates have 

been opened to the point that the provision of easy and secure transactions 

that include single-click procurement of goods, event and locationspecific 

applications, trading, reservations and the ability to participate 

in auctions are possible. With enhanced bandwidth and the advent of 

applications with built-in artificial intelligence to the mobile space in 

2003 and beyond, the mobile Internet will evolve to the provision of 

3.5 

75.9 

12.0 

7.7 

3.0


personalized advice and one-to-one marketing, as well as multimedia 

applications. 

Benefits of mobile Internet technology include: 

Direct data access and collection 

Decision-makers need to ask themselves what elements of operations 

of their businesses may benefit from mobile data at the actual point of 

activity. Already some models are evident. For example, in the area of 

sales force automation and in healthcare, companies are providing 

physicians with access to patients' records and data on drug interactivity 

via their PDAs. Several companies have developed applications that 

permit physicians to write prescriptions on a handheld device, which 

are then wirelessly transmitted to pharmacies. The benefit to consumers 

is that prescribed medications can now be ready for patients when they 

arrive at the drugstore. Errors resulting from hard-to-read prescriptions 

and drug interactions will be eliminated. 

Mobile employees can access centrally stored data in real-time. They 

can also gather and upload data to company servers that can be viewed 

and used by their colleagues and customers back at the office or in 

other locations around the globe. The proprietary handheld data-collection 

devices employed by overnight delivery companies such as FedEx and 

UPS are the most obvious examples of this capability. These companies 

have been performing this type of sophisticated mobile data collection 

for years. More recently, they have developed technological advances 

such as electronic signature capture via pressure-sensitive tablets. New 

developments entail on-the-fly data upload to central servers around the 

globe. 

Accuracy and speed 

Mobile data collection means that information need only be entered 

once before it becomes a part of a company's database. This streamlines 

collection, transcription and access, which result in improved accuracy 

and enhanced speed. These efficiencies can be transferred directly to a


company's bottom line, as redundant processes and opportunities for 

error are eliminated. 

There are numerous everyday examples. A sales representative taking 

a customer's order in the field could easily select a customer's account, 

as well as model numbers, colors and other criteria desired, from preset 

or contextual menus on a mobile device. The order could then be easily 

transmitted wirelessly to the company's back-end servers where the 

customer database resides and where it would automatically enter the 

fulfillment process. Without mobile technology, the sales agent would 

have a number of other more pedestrian options. The agent would 

either need to wait until he reached a networked computer to input the 

order or, alternately, he could fax or call in the order to the home office, 

where another employee would have to enter it into the system. Each of 

these more pedestrian alternatives unnecessarily complicates the ordering 

process, slowing it down and decreasing its accuracy. 

Communications in real-time 

As alluded to earlier, mobile messaging and file transfer applications 

permit individuals to send and receive files without the delay of first 

finding a networked PC terminal. An example is Cendant, the company 

that owns realty franchises Century 21, ERA and Coldwell Banker. This 

forward-looking firm is in the process of equipping all of its agents 

with two-way smart pagers capable of sending and receiving e-mail. 

This will permit the agents, who may be out of the office for considerable 

periods of time, to respond more quickly to customer inquiries. There 

are other examples. At large law firms and investment banks like 

Skadden Arps and Goldman Sachs, professionals receive RIM (Research 

in Motion) Blackberry devices, affording them round-the-clock access 

to e-mail. 

12.3. Wireless Application Architecture 

and Components 

Figure 12.1 is an example of an existing technical architecture that 

integrates a wired Website with a wireless access component.


Mobile Base 

Station 

WAP Gateway ; 

± 

Jill-, 

Base Station; 

Controtier > 

-#• Internet 

Public Access 

Private Access 

App Server 

Web Server 

Hydra 

Web 

Web Server 

it 

App Server 

Figure 12.1. — Existing technical environment 

Production 

Mirror 

Region 

Production 

Region 

Internal 

Database 

As can be seen in this figure, addition of a WAP gateway, which 

interacts with the base station controller, mobile base station and mobile 

phone, permits this wired architecture to have a wireless component. 

Some of the most important components of wireless applications 

include: 

Wireless Network Middleware 

The intermediate software component generally located on the wired 

network between the wireless appliance and the application or data 

residing on the wired network is referred to as wireless network 

middleware. The purpose of middleware is to increase the performance 

of applications running across a wireless network. In order to accomplish 

this, middleware attempts to mitigate wireless network impairments, 

such as limited bandwidth and network connection disruptions. The 

handheld device communicates with middleware, using a wireless 

network optimized protocol. The middleware then communicates with 

the actual application or database, using applicable connectivity software.


Many middleware products possess features that go beyond the basic 

functionality of connecting appliances to applications and databases 

located on the wired network. The important features of wireless network 

middleware are: 

Optimization Techniques — Middleware often includes data compression 

at the transport layer to help minimize the number of bits sent over the 

wireless link. A variety of compression algorithms are employed to 

perform the compression, including V.42bis, Hoffman encoding, runlength 

encoding and proprietary compression techniques. Some 

middleware use header compression. 

Intelligent Restarts — Unfortunately, with wireless networks a 

transmission may be disrupted due to interference or operational 

problems. A recovery mechanism often employed is an intelligent restart 

that detects when a transmission has been cut and when the connection 

is reestablished. With intelligent restart, the middleware resumes 

transmission from the breakpoint, instead of at the beginning of the 

transmission. 

Store-and-Forward Messaging — In order to ensure message delivery 

to users who may become disconnected from the network for a period 

of time, middleware performs message queuing. Once the station comes 

back online, the middleware will send the stored messages to the 

station. 

Screen Scraping and Reshaping — Many middleware products have a 

development environment that enables a developer to use visual tools to 

'scrape' and 'crop' portions of existing application screens to fit within 

the smaller display of data collectors. 

Operational Support Mechanisms — Some middleware products monitor 

the performance of handheld devices through utilities and tools, which 

enable IT personnel to better troubleshoot problems. 

Middleware connectivity often possesses the following attributes: 

Highly efficient operation over wireless networks — Middleware reduces 

the load on the wireless network through the use of optimization 

techniques, such as data compression and screen scraping.


Appliance or host/server programming not required — The preponderance 

of wireless middleware products possess a development environment 

that shields the developer from having to understand the appliance and 

host-based development environments. 

Mainframe to client/server systems migration supported — Many 

companies are migrating from mainframes to client/server systems. 

Middleware is a cost-effective solution for supporting these migrations, 

enabling connections to both mainframes and client/server databases, 

simultaneously. 

Multiple-vendor appliances support — Most middleware products 

interface with a wide variety of handheld devices. 

12.3.1. Wireless Access Protocol (WAP) 

Wireless Application Protocol (WAP) is an open, global standard that 

enables mobile devices to be compatible with the majority of bearer 

networks such as Code Division Multiple Access (CDMA), Global 

System for Mobile Communications (GSM) and next-generation network 

standards. WAP has been constructed on modified Internet protocols 

and permits mobile devices on non IP-based networks to connect to the 

Internet. 

WAP is an application environment and a communications protocol. 

WAP sits astride a variety of wireless carriers and provides services 

such as compression, encryption, the integration of telephony and data 

services and, most importantly, the wireless application architecture that 

permits the building of WAP application programs that run on smart 

phones (i.e., WAP applications). In a practical sense, WAP applications 

deliver WML-tagged, instead of HTML-tagged documents to a browser. 

Usability challenges include the following: Internet on mobile devices, 

small screens, phone keypad, slow connection speeds and no standardized 

browser behavior. An often-mentioned competitor to WML is cHTML 

that has been popularized by Japan's iMode service. 

The success of this standard will depend on the penetration of WAPenabled 

devices, the development and recognition of useful applications 

and the rollout of WAP gateways from Ericsson, Motorola, Nokia and 

Phone.com. Negatives of WAP are associated with the fact that it offers


a somewhat limited development environment, particularly for more 

media-rich devices such as Microsoft's PocketPC and Palms IIIc. 

12.3.2. Wireless Markup Language (WML) 

Phone.com's HDML (Handheld Device Markup Language) served as 

the basis for Wireless Markup Language (WML). WML is a descendant 

of Standardized General Markup Language (SGML) and XML. It is 

optimized for low bandwidth and is specified by the WAP Forum. 

WML looks a lot like Hypertext Markup Language (HTML), but uses a 

deck and card metaphor. It contains variables that can be used in all 

cards in the same deck. 

WML differentiates from HTML in the following ways: it is case 

sensitive, the standalone tags end with a '/', form tags are not needed 

and select lists do not look the same. Tables are not as dynamic as with 

HTML and WML has strong semantics: no errors are allowed. The 

parts of a WML 'page' consist of a deck and one or more cards. The 

top-most card is the first to be displayed. An action can be taken in 

response to other events, such as timer timeouts. A card can also set 

variables that can be used by other cards or WMLScripts. Variables set 

in one card can be used in others, as long as the memory is not erased. 

WML building blocks are cards (e.g., ), paragraph items 

(e.g., , ) text formatting (e.g., , ), tables and 

images (e.g., ), select and anchor (e.g., ), input field and set variables (e.g., ), triggers (e.g., ). 

Since WAP applications are XML-based programs, they must start 

out with a valid XML prologue containing the XML version and a 

pointer to the XML definition of the language being used. Examples of 

code follow: 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

 

 

 

 

 

 

 

12.3.3. WMLScript 


paragraph 

check the Accept and Previous 

buttons 

go to this URL 

perform and action 

close do loop 

end card 

WMLScript is a scripting language that employs procedural logic, 

loops and conditionals that are optimized for small-memory, small-CPU 

devices. It is derived from European Computer Manufacturers Script 

(ECMAScript). WMLScript is integrated with WML, which results in 

a powerful extension mechanism that serves to reduce overall network 

traffic and enhance functionality. Typically, WMLScript is used for field 

validation, device extensions and conditional logic. With WMLScript, 

compiled byte code is transferred to the terminal. Standard libraries 

include: Lang for general purpose math functionality, string processing, 

Universal Resource Locator (URL) processing, WML browser interface, 

dialogue and floating point functions. 

Some representative code is as follows: 

1. 

2. 

3. 

4. 

5. 

6. 

The WMLScript example — Script part 

//random.wmls 

external function getRandom ( ) { 

var r= Lang.random(lOO) 

WMLBrowser.setVar("result", r); 

WMLBrowser.go("random.wml#card2"); 

} 

The WML part which calls WMLScript 

comment 

start of function 

variable 

end of function

1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 

11. 

 

 

Randomize 

 

 

12.4. Wireless Security Issues 


start of wml 

identifies cardl 

title 

do loop which runs 

WMLScript 

close do loop 

closes cardl 

identifies card2 

puts out Random 

result 

closes card2 

end of wml 

The advantages of wireless communication are being overshadowed by 

its weaknesses: low bandwidth, high-latency connections, broadcast 

medium, low power (battery powered) and 'security' risks. 

Security becomes mandatory in such a mobile network, as it is hard 

to restrict access to network resources physically. The necessity for 

security is due to the existence of hackers, viruses, intruders, Internetbased 

attacks, disgruntled current and ex-employees and industrial 

espionage. In this section, we will discuss the threats to the security of 

networks and also how they specifically relate to the wireless network. 

We will also present the security solutions for wireless networks. 

12.4.1. Security of mobile systems 

Data transmission security is an essential part of wireless network 

engineering. Since access to the network cannot be restricted physically, 

cryptographic methods must be used to protect transmitted data and 

network elements. Aspects that should be considered are data 

confidentiality, data authenticity and service availability. 

The mobile system should have functions and protection so that:


• The information is not known to intruders (confidentiality); 

• The information is not altered by unauthorized persons (integrity); 

and 

• The information is accessible to authorized users (availability). 

First generation systems 

Analog cellular systems, such as Nordic Mobile Telephone (NMT), 

Advanced Mobile Phone System (AMPS), and Total Access 

Communication System (TACS) are considered first generation (1G) 

technologies. These systems are nowadays considered quite insecure. 

Cloning of the analog terminals is possible and in some systems 

widespread. Terminal cloning compromises the security of charging, 

which leads to loss of profit and reduces the consumer's trust of mobile 

service. In many cases, the lack of security has been the main reason 

for the decision to prematurely close the 1G networks. 

Second generation systems 

Second generation (2G) systems use digital radio transmission techniques 

and digital speech coding. 2G systems were designed for voice, although 

they now also transport a limited amount of low speed data 

communication. 

The 2G systems include: 

• The GSM family which has been adopted world-wide; 

• Personal Digital Communications (PDC) used in Japan; and 

• Enhanced (digital) versions of the 1st generation United States 

Advanced Mobile Phone System (AMPS) standard; IS-136 TDMA 

and IS-95 CDMA (alias cdmaOne) 

The use of digital technology enhances security in two principal 

ways: 

• Digital technology allows the use of cryptographic methods for 

authentication and encryption; and 

• Monitoring digital transmission on the radio interface requires 

specialized equipment, which is expensive and not freely available.


Most of the state-of-the-art IS-95 CDMA and IS-136 TDMA terminals 

support roaming to the analog first generation AMPS system (dual 

mode terminals). This is currently a major problem for the IS-95 

CDMA and IS-136 TDMA operators as it also expands the AMPS 

system's lack of security to the 2G systems. 

GSM-based mobile systems provide mobile user authentication and 

security over the radio interface as an integrated part of the system. The 

GSM security is based on the trust between network operators and on a 

shared secret key (Ki) stored on the user-subscriber's identification 

module (SIM) and in the Authentication Center (AUC) of the operator. 

Third generation systems 

The third generation mobile systems (3G) will be available soon after 

the year 2002. The security of first and second-generation systems 

is based on the traditional telecom security model (separation of user 

data and signaling data). The third generation mobile systems will be 

IP-based and, at least partially, connected to the Internet. IP-networks 

are 'open networks', which do not separate signaling from the user 

data. This allows malicious users to exploit the faults of the protocol 

stacks to gain access to data or network resources. The 3G systems 

have to adopt a new security policy and build an Internet-like security 

architecture (firewalls, virtual private networking, end-to-end encryption, 

etc.). 

12.4.2. Security issues in WAP 

WAP allows the introduction of hypertext services to mobile systems. 

The services are stored on servers in the network and they are used 

with a browser program from the mobile terminal. Both the operator's 

network and the service provider's WAP servers can be connected to 

the public Internet, thus exposing the WAP stack and servers to attacks. 

The main areas where security should be addressed are: 

• Security between the mobile phone and the antenna; 

• Security between the antenna and the WAP gateway; and 

• Security between WAP gateway and origin server.


The following threats and protection methods are identified: 

• The possibility for viruses and malicious services in the mobile 

terminal. Virus protection is required. 

• The wireless transmission on the radio interface is protected with 

standard GSM security methods. 

• Mobile networks can have unprotected radio links inside the network 

(typically between the base station and base station controller). WAP 

services could be protected by the Wireless Transport Layer Security 

(WTLS) layer. 

• The WAP gateway and the server where the services are stored 

require similar protection as Internet-servers (firewalls, careful system 

configuration, skillful administration and monitoring, etc.). This 

protection is critical for the servers, which implement charging or 

store sensitive user information. 

• The data transmission between the WAP gateway and the server 

needs to be protected by firewalls, IPsec tunneling, or other methods. 

• The new security requirements are similar to the security requirements 

of a company intranet and Web servers. 

Terminal 

The terminal uses WTLS to provide privacy, integrity and authentication 

between itself and the WAP gateway. Phone.com incorporates RSA 

Security encryption technology into the WAP-compliant UP.Browser® 

terminal and Up.Link Server Suite products. Embedded into numerous 

mobile phones, UP.Browser utilizes RSA Security technology to provide 

secure wireless information access from wherever a consumer may be. 

The UP.Browser v4.1 was designed as a WAP 1.1 Class C device, 

which includes all required layers of the WAP stack. Phone.com 

anticipates that the UP.Browser v4.1 will ship with 128-bit encryption 

for US and international markets, based on recent US government 

policy decisions and Phone.com's receipt of US exports authorization. 

Ranging from smart phones like the Nokia Communicator 9000 to 

large, enterprise WAP servers, Nokia incorporates RSA BSAFE security 

components into its products to enable them to offer e-business services


for the mobile Internet market. Nokia relies on RSA Security encryption 

technology to bridge the wired and wireless Internet worlds and provide 

a seamless user experience. 

WAP gateway 

At the gateway, the adaptation layer terminates and passes the WDP 

packets on to a WAP Proxy/Server via a protocol, which is the interface 

between the gateway that supports the bearer service and the WAP 

Proxy/Server (see Figure 12.2). 

The WAP gateway contains transition features from WTLS to SSL 

(i.e., secure sockets layer) and vice versa. It also contains a WML 

encoder that makes the information that goes over the wireless network 

into byte-code. The WMLScript compiler takes the script as input and 

compiles it into byte-code. 

Mobile 

Phone 

Xf> 

Co mm unication 

Tower 

c 

1C 

Origin 

Server 

WTLS-Protocot Conversion-SSLj I 

V , LL| ,,JF ? 

WML Encoder 

Dl 

WML Script Compiler Dl 

isi=J^-«%~


WAP gateway security considerations 

Suppliers of the WAP gateway and network operators take every possible 

measure to keep the WAP gateway secure by: 

• Ensuring that the WAP gateway never stores decrypted content on 

secondary media; 

• Ensuring the removal of unencrypted content from the memory in the 

WAP gateway as fast as possible; 

• Securing the WAP gateway physically so that only authorized 

administrators have access to the system console; 

• Limiting the access to the WAP gateway so that it is not accessible 

from a remote site outside the carrier firewall; and 

• Applying all other security precautions used to protect billing systems 

and the home location register to the WAP gateway. 

12.4.3. Generic mobile solutions 

There are two main solutions, which will be based on whether or not a 

mobile operator is used. 

Mobile operator solution 

In this solution the WAP gateway will be located at the operator's 

end. The operator will connect the mobile world and the Internet 

world by placing a WAP gateway in as a node into the GSM system. 

The origin server will be at the customer's site that will have to take 

the necessary security action to secure the environment. Figure 12.3 

outlines the architecture of the WAP gateway at the mobile operator's 

site. 

Company solution 

Company solution is narrowed down to two possible infrastructures: the 

use of a WAP server or a WAP gateway.

Wap """---_ 

Terminal i 

Wireless 

Network 

WAP Gateway 

Mobile Operator 

SSL 


Internet / Intranet 

» 

1 

WAP Server 

Figure 12.3. — WAP gateway controlled by the mobile operator 

u 

S 

Wa 

Ter 

Wireless Network 

WTLS 

i n ' n a ' j 

, 

_ Internet 

e 

^1 

H * SSL 

WAP 

Satew ay S< 

liver , 

Figure 12.4. — WAP gateway controlled by a company 

Implementing a WAP infrastructure with the use of a 

WAP gateway 

One way to build an infrastructure is to invest in a WAP gateway (see 

Figure 12.4). This means that the company must also have a Web server 

that is configured for WAP. 

Nokia offers this solution to their customers. Typically, a company 

that chooses this type of solution can have a modem pool inside to 

operate entirely on its own. 

Implementing a WAP infrastructure in concert with a 

WAP server 

This solution is based on the fact that the WAP architecture provides 

end-to-end security between the endpoints in the protocol (see 

Figure 12.5) which can be done with a WAP Application Server. A 

WAP application server is a WWW-server with the WAP gateway 

features implemented.


• 

! Wap 

'. Terminal 

Wifeless Network 

WTLS 

I 

WAP Application Server 

Intranet / Internet 

Figure 12.5. — Solution with a WAP application inside the company 

The WAP application server consists of a WML encoder, WMLScript 

compiler, protocol adapters, application logic, content database and 

WML decks with WML scripts. This way the company can set up the 

WAP architecture with only one internal machine. 

12.5. B2B Wireless Applications 

B2B wireless applications enable companies to communicate with their 

users' and customers' wireless devices, delivering business-critical and 

time-sensitive information. According to H. C. Wainwright & Co., the 

total wireless applications revenue opportunity will reach US $15 to 

$18 billion for the consumer market and about $250 billion for the 

business segment within ten years. 

Several B2B software vendors, including Vignette and Broadvision 

are providing solutions to allow a company's employees, customers and 

trading partners to conduct such business-to-business (B2B) transactions 

as purchasing from catalogs, approving requisitions or accessing backend 

applications directly from their handheld devices. 

Let us explore business uses of the mobile Internet and different 

B2B wireless applications. 

12.5.1. Business uses of the mobile Internet 

A corporate requirement to communicate with peripatetic staff working 

away from their offices is not a recent development. Since the dawn of 

civilization, the movement of goods and people between cities and 

towns, or between countries and continents, has been a fundamental


part of commercial life. Today, Fortune 500 companies report that close 

to 40% of their workers are mobile and that the standard mobile 

applications, if any, are e-mail services, productivity applications and 

sales force automation applications that are provided to workers. Opening 

existing Web-based applications to mobile users commonly accomplishes 

this. 

Mobile business-to-business (B2B) e-commerce with requirements 

for submitting bids, tracking RFQs (Request for Quote) and authorizing 

purchase orders appears to make sense for all parties. This is because 

business people cannot afford to wait. The technology inclusion does 

not pose a barrier and e-marketplaces must run just to stay in place. 

By the end of 2001, mobile functionality via SMS, WAP and PDAs 

may well become a requirement for both e-marketplaces and technology 

vendors, particularly those that target small to medium-sized enterprises. 

The implications of this are that mobile specialists will see a dramatic 

rise in business, bulk SMS resellers will proliferate and this will force 

customer relationship management (CRM) and sales force automation 

(SFA) vendors to respond. As legacy-free B2B vendors make mobile 

functionality the rule instead of the exception, these CRM and SFA 

vendors will finally be spurred into action. 

An example of mobile B2B e-commerce 

The company bluecycle.com performs online auto salvage auctions. 

Currently 40% of the bids arrive not from PCs, but from mobile phones 

via SMS and WAP. A focused audience of approximately 1,000 

individuals in the United Kingdom who buy crashed cars and either 

break them down for scrap or repair them for resale-is targeted. Most 

are self-employed or work for small businesses and are constantly on 

the move to review prospective inventory. 

Bluecycle.com offers a simple mobile service. The user first 

establishes an account at bluecycle.com's Website. Afterwards, users 

can utilize the mobile service in two ways. First, all mobile users can 

elect to receive SMS messages when they've been overbid by another 

bidder or have won a particular auction. Second, WAP-enabled users 

can log in with a user name and password on their phones to review


new auctions, check status and submit bids. After six months, it has 

been determined that 40% of bids at bluecycle.com arrive from mobile 

phones. Focus groups have shown that early users find the service to be 

indispensable, which may be a harbinger of things to come in associated 

industries which require specific, timely information. 

12.5.2. B2B wireless portals 

The EIP (enterprise information portal) is a term for a Website that 

serves as a single point of access to a company's information and 

knowledge base for employees and possibly for customers, business 

partners and the general public as well. The value of the enterprise 

portal lies in its ability to provide a single access point to disparate 

information for diverse individuals. With wireless access and the unique 

ability of the mobile device to offer end-users a personalized and 

remote communications device, the role of portals will rise in importance 

as a link and gateway to various corporate services. Users will be able 

to access services and content that leverage the unique features of 

mobility, such as location and time sensitivity of information, that fixed 

Internet portals cannot provide. 

The ability to provide wireless access to portal content will be 

increasingly important to remote workers. The ways in which portal 

products aggregate, integrate and access content vary substantially. 

Some are built around crawling or polling technologies that essentially 

build indexes and schemas that identify content topics and locations. 

Others integrate with specific content and data sources to expose content 

from these sources via the interface. In this environment it is important 

to consider support for wireless standards in any corporate portal strategy. 

The Delphi Group considers that, despite the rapid competition and 

innovation among manufacturers of mobile information appliances, the 

real innovation in ubiquitous computing lies in extending the business 

portal software to new devices. Their research found that what they 

refer to as the 'untethered' business portal is the vital link for the 

mobile workforce and that it contributes greatly to making the entire 

concept of mobile access for B2B effective. 

Linking such activities to wireless devices and the increasing numbers 

of workers away from the office are now vital considerations. For


example, the mundane ability to fill out expense reports in real-time has 

cost and efficiency benefits for companies that can make effective use 

of centrally administered enterprise resources. 

Portals should be able to scale easily to hundreds of thousands of 

users and support users on a range of platforms, including PCs, mobile 

phones and handheld devices. 

Business portal software is rapidly becoming a point of convergence 

for the enterprise. Mobile professionals want to take their business 

portals with them. Within a few years, untethered points of access to 

enterprise portals will make the problems of 'synching' and docking 

PIMs and PDAs obsolete. 

12.5.3. On-demand trading 

A growing cadre of new e-marketplaces is establishing dynamic venues, 

such as auctions and exchanges, that allow buyers and sellers to establish 

prices in real-time. In these markets, firms won't just participate in 

these venues, they will configure online markets for each transaction. 

They will do so by trading across multiple product attributes and giving 

their favored suppliers special treatment. 

To achieve this level of personalization and a dynamic pricing 

environment, the e-marketplaces will have to provide real-time 

information about market activities to all the users on all types of 

devices, including wireless. 

With on-demand trading, truckers, for example, will be able to post 

capacity or a bid on a load whenever they want. The result will be that 

some traveling commodity managers will expect to bid through wireless 

devices and respond in the same way. 

12.5.4. Business-to-employee (B2E) connections 

There are few who now doubt the impact of the Internet revolution. It is 

ironic that the need to be wireline connected to an office network or 

intranet has ensured that physical location is still necessary for most 

knowledge transfer in the workplace. Whether production, sales, or 

shipping took place elsewhere, the office's status as the primary location


for the gathering, processing and sharing of information throughout the 

company has remained unchanged. 

As alluded to earlier, another revolution is sweeping the business 

world: the Internet is becoming untethered and there is a demonstrated 

need for B2E (business-to-employee) interactions. Employees no longer 

need to be shackled to fixed Ethernet connections to send and receive 

data. Handheld devices can now connect them to customers, colleagues 

and data wherever they may roam. In short, the mobile Internet is 

finally forcing companies to question the previous notion that the office 

was indispensable as a physical presence for information to be gathered, 

processed and passed. The result is that now an office can be wherever 

employees, their colleagues and customers want it to be. 

Each industry has unique ways of approaching the mobile Internet 

and there cannot be a single or even small set of solutions for different 

industries. As an illustration, Figure 12.6 outlines a typical pathway for 

mobile content delivery. 

Two general ways that firms can exploit mobile technology are 

internally and externally. Internally focused mobile applications leverage 

" VaTTous" 

Back-End 

Systems 

Content >i 

Management; 

Vignette j 

Content 

Delivery 

Epi centric 

Web Portal 

User PC 

Middleware 

Components 

Aether Systems I 

WebObjects j 

WebSphere >• 

WebLogic I 

• Provides translation of 

HTML content to support 

different devices 

p Provides device 

management cap abilities 

• Adds additional layerfoi* 

scalability 

• Enables rapid application 

development 

Gateways 

rj'l a 

HIJ v i. i_m 

IrEach gateway maybe 

combined with third patty 

add-onsto supplement 

the offenng (security 

additional API support} 

Devices 

' ina-L P : ior-?s 

.,iii..y.'.s îjti 

V.i.\'!\'i ' -iti ds 


the power of mobile technology among a company's own employees. 

They are the focus of this section. Externally oriented mobile applications 

reach customers and clients through their handheld devices. 

Internally focused mobile applications that eliminate or hasten 

repetitive or time-consuming processes permit companies to reap the 

benefits of improved operational efficiencies with the provision of 

means for employees to access and to transmit data at the point of need, 

and employees are empowered to be more effective and productive and 

thus streamline business processes. 

Some examples of B2E applications are: 

• Field workers can access project records remotely while in the field 

or onsite at a client's offices. Claims adjusters in the field can 

immediately complete electronic forms on a handheld device and 

upload their reports to a central server, saving time and improving 

accuracy. 

• In places such as hotels, casinos and department stores, employees 

can roam the premises, while retaining access to the company network. 

• Before meeting new or existing customers, sales representatives can 

access the latest inventory levels, product line data and pricing 

structures. 

• Factory workers can track product batches as they progress through 

production or assembly without needing to return to a fixed terminal. 

• Consultants and other business professionals can avoid manually 

updating contact lists on their PDAs or daily planners by 'synching' 

these devices with a central company database. Interestingly, this can 

also be configured to be accomplished upon entry or exit of an 

employee to an office's local wireless LAN. 

12.5.5. B2B, B2C, B2E and wireless 

B2E like B2B and B2C has, heretofore, been wired, though it is 

evolving towards wireless applications. So long as there is a need for 

(a) ubiquitous access to information; (b) convenience and accessibility; 

(c) personalization; or, in the near future, (d) localization, there is a 

possibility that wireless can play a role. The most salient present


constraints are bandwidth and the complexity of the underlying networks 

in the United States. 

Thus, it appears that B2B does not naturally lend itself to wireless. 

B2C can, and will, morph from e-commerce primarily directed at wired 

individual consumers to both e- and m-commerce in select industries 

(e.g., travel and entertainment or banking). B2E, similarly, will have 

applications in the CRM and SFA realm, which will have elements that 

can be accessed in both wired and wireless formats. 

12.6. Enterprise Integration Issues 

for M-commerce 

Much has been written about B2B e-commerce, but little has been set 

down about the preparation and protection of these same enterprise 

systems for mobile e-commerce. This section examines the history of 

remote access to enterprise e-commerce systems and attempts to identify 

particular issues and challenges mobile B2B e-commerce presents. 

Mobile e-commerce has some specialized issues relating to the 

separation of wireless user access from Internet latency and secure data 

because of multiple air interfaces in use (i.e., from the handheld to the 

transmission tower and from there to the gateway at a carrier or within 

a firm). In the United States, particularly, this is a problem because 

there are three air interfaces in use on the public networks: GSM 

(Global System for Mobile Communications), CDMA (Code Division 

Multiple Access) and TDMA (Time Division Multiple Access), as well 

as three packet networks, ARDIS, Mobitex and CDPD. Apart from slow 

speed (9.6kbps), GSM in particular has significant latency implications 

from an enterprise standpoint. 

The issue of speedier and more secure transmission of corporate 

data over comparatively slow wireless links is being addressed by a 

new group of tool builders who are developing applications which are 

network resident, or especially designed to be accommodated on small 

handheld wireless phones. However, the issue of developing an audit 

trail for billing and non-repudiation of transactions appears to be more 

complicated than in traditional remote access over wireline networks. A

1 


GSM h HSCSD h GPRS fc EDGE fc UTR.A WCDMA 

9,6 - 14.4 - *" 57.6 Kbps - "*" 176 Kbps - "^ 768 Kbps - r 2 Mbps 

Kbps I JL 

1999 2000 2001 2002 

Figure 12.7. — The migration to 3G networks 

way to address this shortcoming is through enhanced user authentication 

and location profiling which is a byproduct of real-time call rating. 

Still another set of latency issues arise in the transcoding (i.e., 

presentation and adaptation) of Internet data for display and processing 

on wireless devices. Websites combine presentation and content data 

using HTML, which must be transcoded for wireless device use. Use of 

XML gets around that problem. Widespread adoption of the WAP with 

its XML-compliant WML has provided an interim solution. However, 

conversion of WAP at a carrier's gateway poses a security risk for the 

enterprise. While 3G wireless and wired broadband networks will 

ultimately use end-to-end IP (Internet Protocol), enterprise solutions in 

the near term are likely to require middleware to ensure security and 

high throughput for transactions. Figure 12.7 outlines the migration to 

3G networks. 

As wireless devices become smarter, faster and more powerful, they 

will undoubtedly pose a new enterprise security risk. It is anticipated 

that these devices will exchange not only voice and data, but also 

executable code. Distributed object frameworks support remote invocation 

of code. As mobile IP, distributed object frameworks and mobile code 

technologies, such as Java and Jini, merge in the future, it is safe to 

assume that we will have new security and privacy risks. 

If a company is looking to deploy some kind of wireless business-tobusiness 

solution, there are three basic, but very important things one 

can do to protect one's data now and limit the impact of IP theft: 

1. The more network-centric solutions designed a priori, with the least 

amount of sensitive data residing in the handheld, the better off one 

X


is. The PDA can hold the browser and forms, but data should not 

reside there. Among the cognoscenti, it is well known that current 

handhelds, particularly the Palm devices, have such limited processing 

power and storage capability that it is hard to put any kind of serious 

virus protection on the device. Pocket PC devices are better suited 

for this, as they will soon have Intel Pentium-level or Strong Arm 2 

(600 MHz) processors and more storage. 

2. A server-type certificate built into the client is an excellent idea. 

This is important because the client then authenticates the server 

before the password is used from the network to authenticate the 

client. This prevents 'spoofing', in which a user uploads sensitive 

data to what he thinks is his network server, but which is not. This 

method calls for mutual authentication before any sensitive information 

is shared. 

3. For most wireless networks, it is advisable to put an additional layer 

of security on top of the built-in security mechanism. It is widely 

recognized in the industry that one cannot rely on GSM security 

alone. CDMA has stronger security natively and CDPD, Mobitex 

and Ardis typically need to run an application layer on top of their 

native security. Most of the built-in security is robust enough to stop 

someone with a scanner from seeing plain text, but there is very little 

that cannot be defeated by a computer cracker. Deciding on how 

much security one layers on, the transmission becomes a tradeoff in 

performance and cost. In essence, what needs to be done, unless one 

wants to use a no-compromise deployment from end-to-end and 

spare no expense, is to match up the level of access or services to 

the wireless network's capabilities to handle security. 

There are at least three tiers of services one can match to wireless 

network capabilities. Tier one would be where users simply view 

information, such as bank account information. In tier two, closed 

transactions would be acceptable, where information can be exchanged 

or money transferred, to continue the bank analogy, within the same 

institution. Tier three, the highest level of security, would use end-toend 

encryption to allow users to exchange information with other 

companies or transfer money between various banks.


12.7. Leading M-commerce Solution Providers 

Table 12.3 shows the leading wireless solution providers: 

Several application server providers, such as BEA — WebLogic 

and IBM, and WebSphere Everywhere Suite also provide support for 

m-commerce solutions through their platforms. 

12.7.1. BEA WebLogic m-commerce solution 

The BEA WebLogic m-commerce solution enables enterprises to run 

reliable and scalable e-commerce solutions on a single infrastructure 

that serves dynamic content to wired PCs and wireless personal digital 

assistants, pocket PCs, pagers and cell phones (see Figure 12.8). 

Based on the WAP, the BEA WebLogic m-commerce solution 

integrates BEA WebLogic server and BEA WebLogic commerce server 

with the Nokia WAP server and is compliant with all WAP-enabled 

wireless devices. With the BEA WebLogic commerce server, businesses 

can make the best use of tiny mobile displays to deliver customized 

information and services to individual wireless customers. Furthermore, 

Client 

Wireless 

PDA 

Partner 

Offerings 

Campaign Manage! 

Commerce Server 

Personalization Server 

Legacy 

Applications 

Mainframes 

and Databases 

eUnk 

Partner 

Gffeimgs 

Web logic Integration 

WebLogic and Tuxedo Application Servers 

BEA Services 

ft 

Partners 

mh 

Suppliers 

Employees 

Internet Customers 

Figure 12.8. — BEA's WebLogic provides m-commerce solution

Company 

Brience 

Everypath 

GadgetSpace 

NetMorf 

Products and 

services 

Brience Framework, 

Wireless Edge 

Server 

Everypath Mobile 

Application 

Platform 

GadgetSpace 

MobileMediary 

service 

SiteMorfer 

Table 12.3. Leading M-commerce solution providers 

Description (including key 

technologies used) 

Works with existing apps 

infrastructure to extend all 

e-business apps to any Webenabled 

wireless device. 

Mobilizes business apps, XML 

interfaces, transactional Webbased 

data and database 

information. 

Instantaneous, bidirectional 

dialog between any Internet 

app and any Internet-capable 

mobile device. 

Automatic content conversion 

via SiteMorfer Mark-up 

Language (SML) for access by 

all mobile devices. 

Partnerships and 

alliances with other 

companies 

BroadVision, Cisco, 

E.piphany, Lucent 

Technologies 

Check Point Software, 

Engage, Interwoven, 

Network Appliance 

CalendarCentral, 

Clarkston 

Allaire, Clarkston, 

Mercator, Mobilocity, 

SignalSoft 

Key websites using 

products and services 

BarPoint.com, 

Hyperion, Ingram 

Micro 

Alaska Airlines, Best 

Buy, E*Trade, 

salesforce.com 

Celanese Chemicals, 

MGM, Symbol 

Technologies 

barnesandnoble .com, 

CEOExpress, MyPalm

2Roam 

Company 

Products and 

services 

2Roam Catalyst 

Wireless Server, 

2Roam Nomad 

Wireless Publisher 

Source: PC Magazine, February 2001 

Table 12.3 (Continued) 

Description (including key 

technologies used) 

XML-based. Intelligently 

harvests content off-site or 

integrates with data systems to 

deliver static or dynamic content 

to any wireless device. 

Partnerships and 

alliances with other 

companies 

AdForce, Akamai, 

Avenue A, DoubleClick, 

iQ.com, SignalSoft 

Key websites using 

products and services 

eBay, Fogdog, 

iOwn.com, 

SalesHound.com, uBid, 

WorldPages.com


this solution is designed to protect the confidentiality of sensitive 

customer information across all communication channels. 

12.7.2. IBM's WebSphere everyplace suite 

IBM's WebSphere everyplace suite is server software that extends 

network connectivity to a wide variety of wireless protocols, synchronizes 

device databases with server databases and delivers content reliably. It 

accommodates a variety of connectivity gateways, including WAP, GSM, 

CDMA, TDMA, and TCP/IP, and securely communicates with wireless 

devices. By extending essential business-to-business transactions to 

wireless devices, participants can remain engaged from anywhere, thereby 

increasing market efficiency. 

12.8. To be or not to be... Wireless: Pertinent 

Strategic Considerations 

The mobile Internet will not supplant the PC-based Web experience that 

we now enjoy. Rather, the promise of the mobile Internet today is that 

it will expand the reach of the Internet, even though the browsing 

experience on a handheld will probably not resemble what we see on 

the traditional Web. The mobile Internet represents a new tool for 

businesses. It permits them to connect their employees and to streamline 

their processes in ways previously thought to be unwieldy, expensive or 

impossible. 

12.8.1. Goal and business definition 

Building an application is similar to building a house. Goals must be 

defined clearly in the beginning and plans must be drawn up before the 

actual coding commences. Companies should think first about the nature 

of their existing operations and where in those processes mobilization 

could play a role. This could be through the speeding up or elimination 

of various processes, the freeing up of employees from their desks 

so that they could spend more time in the field, improving access


to information, or simply enhancing communication throughout the 

enterprise. 

Several key questions are immediately evident: 

• What are the specific goals of mobilization? 

• Which business processes are candidates for mobilization? 

• Who in the company will take ownership of the initiative? 

• Is there support from upper management? 

Essential questions for implementing B2B mobile models 

As always, when focusing further on a new technology, pertinent 

questions start to surface. Any company implementing B2B mobile 

models should consider the following questions: 

1. How well do the bundled applications work in a small handheld form 

factor? If the handheld is too hard to use or if the applications are 

difficult to see on a small screen, the device may look useful in a 

demonstration but will fail in regular everyday use. 

2. Has the battery life been sacrificed for extra features? Battery power 

is a vital factor and any device that offers unnecessary applications 

will require the user to carry additional batteries or be tied to a 

power outlet, directly impacting mobility. Note that in remote areas 

there may be only limited access to batteries and recharging facilities. 

3. Are users willing to pay for bundled features they may not need? 

According to the detractors of Microsft's PocketPC, users are given 

little choice in this matter. 

4. Will the operating system appeal to developers? Earlier versions of 

Windows CE (Compact Edition) encountered problems in this area, 

and without a large community of developers creating new 

applications, Windows CE became a metaphorical 'island in a stream'. 

5. Are expansion options available for the handheld? For example, Palm 

users can choose multiple expansion technologies, enabling over 

500 expansion options, with more on the way every day. 

This debate between suppliers of operating systems and various 

vendors illustrates just one of the many issues corporate IT departments 

need to grapple with in implementing mobile business solutions. Gaining


a clear idea of what is offered through the smokescreen of competing 

vendor claims is not an easy task. Putting sensitive, mission-critical 

data into devices that are designed to go anywhere creates management 

challenges that include security, software distribution, data flow issues 

between a mobile device and a PC or directly with a server, automating 

enforcement of company policies, centralized backup and restoration, 

remote troubleshooting and the prevention of viruses from passing into 

the corporate network. This will require a comprehensive set of security, 

data synchronization and systems management functions to overcome 

potential problems. 

12.8.2. Formulation of technology strategy 

Once the specific goals for mobilization have been identified, it is then 

recommended to conduct a high-level technical analysis of how the 

solution will be realized. The mobile environment is so complex and 

evolves so quickly, that a diverse array of options demands a careful, 

strategic approach. Some of the primary choices to be made in developing 

mobile applications include how users' devices will send and receive 

data, the identification of those devices and what applications they will 

run. Because early choices impact other options, it is important to view 

the choices made as an interdependent system of options, rather than a 

series of isolated decisions. For example, the need to gather and transmit 

large batches of non-time sensitive data may easily lead to choosing 

PDAs that synchronize to a central database. Conversely, a decision that 

global wireless coverage is absolutely required will mandate the selection 

of particular devices running certain types of applications. 

Build or buy applications 

Mobile applications can range from simple SMS-based alerts, to complex, 

locally stored programs. As with other, non-mobile applications, they 

can all be obtained via vendor offerings, or through custom development. 

There is a wide array of vendors that offer mobile 'point solution' 

applications or suites of applications that perform particular functions, 

such as sales force automation or scheduling. The benefits of choosing


a vendor's software product often include reduced time-to-market and 

lower cost. However, the disadvantages of these products are limited 

customizability or adaptability to the unique methods of a business 

operation. In addition, these off-the-shelf products may not be easily 

extensible when new technological developments appear. It is important 

to remember that because mobile technology is developing rapidly, 

with new devices, networks and protocols continually emerging, the 

adaptability that custom development brings may be an essential element 

of a long-term strategy. 

Many ways to data transmission 

Data transmission refers to the means by which data is sent and 

received by a mobile device. When thinking about data transmission, it 

is important to consider a variety of factors relating to how the eventual 

mobile application will be built and how it will actually be used in the 

field. The right solution for one's company will depend on a number of 

issues, such as timeliness and time-sensitivity of information, as well as 

geographic coverage. 

Real-time wireless versus 'synchable' data 

The choice between wireless and 'synchable' wireless solutions depends 

primarily on the time sensitivity of the data at hand. Many quite useful 

mobile applications never establish a wireless connection to the Internet. 

Instead, they synchronize locally stored data with that on a server. 

'Synchable' solutions are often superior when large amounts of 

information are to be transferred. This is because they rely on a serial 

port or an even faster Universal Serial Bus (USB) connection. In a 

practical sense, sending a megabyte of data over most current wireless 

networks would be all but impossible, as their limited bandwidth would 

reduce the data flow to a trickle. Another factor to consider in deciding 

between 'synchable' and real-time wireless is network coverage. If 

users will frequently be in locations where a wireless carrier's bearer 

network coverage is spotty or absent, even the most powerful mobile 

application will be of little value.


Is data pushed or pulled? 

Another factor to consider is whether data will be pushed to individuals 

or pulled by individuals. Push-based data transfer lends itself to timesensitive 

information requiring interactivity from the recipient. An 

example is whether to reschedule a planned meeting upon receiving 

notice that one of the invitees cannot attend. Push functionality may be 

achieved through various technologies: Short Messaging Service (SMS) 

messages, browser alerts to WAP phones, or e-mail to an 'always-on' 

device. The type of underlying network available will determine which 

of these options are viable. 

For example, 'packet-switched' bearer networks (used by two-way 

paging devices) are 'always on'. They do not require the user to 

establish a network connection before receiving data which makes this 

type of network an ideal choice when the timely receipt of wireless 

e-mail is absolutely necessary. Conversely, 'circuit-switched' networks, 

such as those used by digital and PCS (Personal Communication System) 

mobile phones, require that a connection be established, but offer the 

additional benefit of carrying voice-based communications. 

There are other factors to consider. In the American market, the 

patchwork of competing PCS and cellular carriers means that packetswitched 

networks have a greater geographic coverage than any one 

circuit-switched network. Companies seeking to standardize on one 

device for employees traveling throughout the country may choose 

always-on connectivity for this reason. 

Local mobile (LAN) versus roaming mobile 

In offices where employees want to move freely within a limited area, 

wireless LANs may be the ideal solution. By establishing a wireless 

LAN, a company can equip employees with handhelds that access its 

network over an always-on connection from within a relatively short 

radius, with much higher bandwidth than would be possible over widerange 

bearer networks. Some hotels equip their staff with handheld 

devices that track room status and inventory levels in real-time and 

many supermarkets employ this technology to update inventory.

A growing panoply of devices 


Not all mobile devices are created equal. The relatively large screens 

and pen-based input system of many PDAs and two-way pagers make 

them well suited to display relatively large amounts of data from 

spreadsheets, maps, or graphs at once. Phones can exploit VoXML 

(Voice Extensible Markup Language) and associated voice-navigation 

technologies, but often suffer from poorly designed physical interfaces. 

Emerging hybrid devices combine the strengths of both PDAs and 

phones, but may suffer from trying to do too much. 

Within any given device class there can be a few and in some cases, 

many, potential manufacturers and models to choose from. In many 

firms, once a general device class, such as a smart phone or PDA is 

decided upon, just one model in that class is approved for employees. 

One of the key benefits of designing internally focused, as opposed to 

customer-focused, external, mobile applications is the control over the 

end device which can greatly simplify application development, enhance 

security and overall design, testing and troubleshooting. 

Extension of the web infrastructure 

In considering a mobile solution, attention should be directed to existing 

legacy systems, a company's Web infrastructure and any middleware 

platforms to be used for particular features such as 'synching', alerts, or 

instant messaging. It is highly likely that a certain amount of custom 

software development may be called for, even if an off-the-shelf solution 

is employed. 

In addition, firms should already be thinking about leveraging an 

XML-based architecture, which will permit companies to keep data in 

its raw form and package it into its appropriate format depending on the 

channel being reached. This evolution is necessary to address an 

inexorable trend: the PC is becoming but one channel among many for 

the delivery of data. 

User-level design 

As with wired Web-based projects, a company's mobile initiative can 

succeed or fail if the user-level design is not well considered. At this


juncture, questions are not about high-level strategic choices among 

vendors or platforms, but rather of user-level concerns: interface design, 

site structure and layout. In the world of the mobile Internet, small 

displays, clunky input mechanisms and slow network speeds can all 

conspire to detract from the user experience and derail the mobile 

initiative. 

Navigation considerations are important. The more the levels of an 

application's hierarchy a user must navigate, the greater the opportunity 

for erroneous input, which will often result in slowing down the process 

further. 'Flattened' application hierarchies attempt to keep vital data as 

few 'clicks', or levels away from the user task completion, as possible, 

at all times. Employment of context-sensitive 'soft' keys can aid this 

process by putting the most likely choices at the user's fingertips. 

Personalization will be important in the mobile realm. For example, 

when only one or a few employees will be using a particular device, 

their individual preferences and user information can be stored either 

locally or on a central server, to speed up the navigation process and, 

ultimately, their access to data. As an example, a sales agent's phone 

can store his user ID and password, so that upon accessing his company's 

WAP site, he is automatically logged in, with contact information for 

his key client leads and sales figures for the product lines he covers 

readily available. 

A more creative and practical use of personalization may involve 

having a user configure the wireless application preferences on a PC. 

The preferences would then be accurately reflected when the user 

activates his mobile device. For example, a banker could configure a 

'synchable' application via their PC so that upon accessing their 

company's back-end server over the Internet, he or she downloads data 

on acquisitions only in a particular industry or sector. 

In the world of the mobile Internet, the minimization of what is 

transmitted is important. This is because slow network speeds will 

translate into longer latency, which will frustrate the end user. It is 

important to remember that, for example, in the case of WAP phones, 

exceedingly small displays mean that the amount of data displayed at a 

single time should also be minimized. 

A company can reap the rewards of the mobile Internet more quickly 

when it is used frequently by many employees to share information.


This harvest can be realized more quickly if the online wireless 

experience is standardized. As the availability of networks with 'fat 

pipes' to transmit more data, more quickly, takes hold, the value of a 

mobile initiative increases dramatically. 

A way to reap this reward is for companies to minimize resistance to 

mobile applications by settling on interface standards where possible. 

Much of the standardization of elements in Microsoft Windows 

applications has permitted users to learn new programs quickly and 

easily. Thus, maintaining the homogeneity of mobile devices and 

interfaces within a firm will encourage mobile application use, facilitate 

internal (and external) data transfer and allow for a thorough integration 

of mobile components into existing operations. 

Implementation 

Due to the proliferation of devices and networks, testing takes on a new 

level of importance and complexity in the mobile world. An application 

that works as intended on a particular device or bearer network may 

reveal hidden glitches on another. This is also true for different devices. 

Thorough testing of mobile applications therefore demands functionality, 

stress and regression testing on as many devices to be supported and, 

where applicable, as many underlying networks, as possible. Companies 

can standardize on a single technological platform to simplify the 

testing process. Often this is not an option, as support for multiple 

devices may be necessary. 

As noted earlier in this chapter, the only constant with the mobile 

technology landscape is change. Companies that roll out cutting-edge 

mobile applications to their employees today must continue to roll out 

better versions of the same applications tomorrow if they want to stay 

ahead of their competitors. In both the wired and wireless worlds, what 

is required is an ongoing evaluation of a company's strategy and 

solution against new technologies, products, devices and software. 


We are on the verge of an explosion in wireless use. By 2003, there 

will be 400 million mobile Internet users. By 2005 there will be one


billion cell phones in use. Today, Fortune 500 companies report that 

close to 40% of their workers are mobile and that the standard mobile 

applications, if any, are e-mail services, productivity applications and 

sales force automation applications that are provided to workers. 

A wireless business portal is a vital link for the mobile workforce 

and contributes greatly to making the entire concept of mobile access 

effective. 

Handheld devices are now moving from a role as personal productivity 

tools to providing enterprise-wide business solutions. In effect, they are 

extending the reach of the enterprise and the use of mission critical 

applications wherever they are needed. 

In considering a mobile solution, attention should be directed to 

existing legacy systems, a company's Web infrastructure and any 

middleware platforms to be used for particular features such as 

'synching', alerts, or instant messaging. It is certain that custom software 

development will be called for, even if an off-the-shelf solution is 

employed. 

Wireless technology will play a crucial role in B2B interactions and 

transactions. It would enable the users to query an integrated backend 

system, such as SAP R/3 and have the response forwarded to other 

wireless devices: laptops, WAP-enabled phones and PDAs.

Chapter "] 3 

Software Agents 


The opportunities for using intelligent software agents in B2B applications 

are enormous. They will not only assist in coordinating tasks 

among humans but also communicate, cooperate and collaborate among 

distributed programs. 

This chapter explains the fundamentals of software agents vis-a-vis 

B2B integration, types of software agents and features of intelligent 

mobile agents. We also cover the different applications of software 

agents in B2B e-commerce applications, along with the universal 

language used by the agents — Agents Markup Language (AML). 

381


13.1. Software Agents Enabling the Formation of 

Virtual Organizations 

B2Bi requires companies to go through a big structural change, wherein 

the hierarchical, coordinated organization model is replaced by the 

decentralized business network, leading to virtual organizations. 

In order to have operational efficiency and productivity, virtual 

organizations should be able to communicate, cooperate and collaborate 

with each other in real-time. However, there is a need to ensure that the 

rise in productivity is not lowered or even over-compensated for by the 

overhead of coordination efforts required among cross-organization 

departments. 

The Solution: 

Software agents are an effective tool for virtual organizations because 

they provide mechanisms to automate several activities, such as gathering 

and filtering information, negotiating deals and synchronizing business 

processes and workflows. Intelligent software agents can work on behalf 

of human knowledge workers, be it supplier or buyer or both. 

Software agents find applications in a variety of domains, including: 

B2B e-commerce, Internet-based information systems, robotics, smart 

systems, decision support systems, data mining and knowledge discovery. 

This chapter focuses on the role of software agents in B2B e-commerce 

and B2B integration. 

The opportunities for using intelligent agents in B2B applications 

are enormous, mainly because the fundamental need of buyers over 

the Internet is to find the best price and that of sellers is to get an 

optimum price from buyers and multiply sales. These needs give rise to 

a variety of intelligent agents working for B2B buyers and sellers. 

Agent technology can also be very useful in searching the Internet or 

an Intranet, negotiating deals and automating customer relationship 

management, supply chain management and market pricing. 

13.2. What are Intelligent Software Agents 

An intelligent software agent is essentially a program that autonomously 

senses the environment, acts upon it and adapts to the environment with

Software Agents 383 

time. These agents do not act in isolation, but in the presence of other 

humans and agents. They have to cooperate and execute a task to 

achieve the desired goal. Intelligent agents have the ability to plan and 

set goals, reason about the effects of the actions and improve their 

knowledge and performance through learning. In short, intelligent agents 

are active, persistent (software) components that perceive, reason, act 

and communicate. 

Humans can reduce information overload and work overload by 

delegating tasks, which they would prefer not to do to these intelligent 

programs. As the intelligence of software agents grows, companies 

using them will become more time responsive, efficient and profitable 

since their supply chain processes, customer relationship processes and 

internal processes will be more responsive to changes in price, availability 

and other external and internal factors. 

An intelligent agent should be: 

• Social — one that interacts, negotiates, coordinates and cooperates 

with other agents; 

• Reactive — one that absorbs new information, responds to the changes 

in environment and constraints; 

• Mobile — one that is engaged in e-commerce travels from computer 

to computer, gathering information until search parameters are 

exhausted; 

• Persistent and Goal-Oriented — one that does not require constant 

attention from human beings and is driven towards defined and 

established goals; 

• Communicative/Collaborative — one that communicates and collaborates 

in a multi-agent environment and sends and receives information 

to and from other agents, using appropriate protocols. This requires 

communication services supporting message queue management, 

asynchronous messaging and content-based routing of messages; 

• Flexible — one that deals with heterogeneity of other agents and 

information sources; 

• Adaptive/Learning — one that observes and learns from the users 

and other agents and adapts to the needs of the owner; 

• Autonomous — one that acts on behalf of humans without their 

intervention;


• Proactive — one that acts to achieve goals; and 

• Able to perform directed tasks — one that takes directions from 

human beings or other agents and performs the directed tasks. 

13.3. What are Agent Systems? 

Agent systems provide an environment for the execution of software 

agents. As an application framework provides a set of services for the 

execution of the application-related actions, an agent framework provides 

a similar set of services for the execution of agent actions. Typically, 

an agent framework would provide services, such as the ability to 

communicate with other agents, maintain the current state of executing 

agent and provide secure platform for code execution. 

13.4. Agent Classification 

Agents can be of the following types (see Figure 13.1): 

Payment 

Mobile 

Seller 

User 

Interface 

\ 

Bui ier 

, - - • " " • 

"-•-/ 

i Types of 

\ Agents 

/ 

r--" > 

Inforn nation 

/ 

Negotiating 

."'*•**•"--- C 

\ 

Reactive 

eliberative 

Collabora itive 1 

Figure 13.1. — Agent classification

Interacts with 

•IIIIIMIMIIIIIIIIIMIIIIIIIMIIIMIMIIMIII Usei' 

Application J Observes & 

I Imitates 


Corrmun ic ation Concept Lear ni ng 

Agent I 

User Interface L 

Interacts with ,.„^fL. .-J Provides Feedback to 

Figure 13.2. — User interface agent 

User Interface Agents — User interface agents usually provide assistance 

to a user dealing with a particular application (see Figure 13.2). The 

metaphor is that of a personal assistant who is collaborating with a user 

in the same work environment. 

Information Agents — An information agent is an agent that can answer 

the queries of users by gathering, filtering, processing and manipulating 

information from at least one data and information source. 

Collaborative Agents — Agents that communicate, i.e., share information 

and collaborate on a common task are called collaborative agents (see 

Figure 13.3). 

Mobile Agents — Agents that act on a user's behalf and are able to 

migrate over a network in a controlled fashion are known as mobile 

agents. The agent decides its own path of migration, time of execution 

and acts if it has to terminate its execution. It returns results and 

messages in an asynchronous fashion. 

Reactive Agents — Agents that respond to activities in the current state 

of their environment are labeled as reactive agents. 

Deliberative Agents — Agents that plan and reason to achieve coordination 

with other agents are addressed as deliberative agents. These 

agents possess an internal representational and reasoning model. 

Matchmaking Agents — Matchmaking agents act as intelligent mediators 

between buyers and sellers.


Smart 

Agents 


Learning Agents 

Collaborative Interface 

Agents Agents 

Source: Hyacinth Nwana (1996) 

Figure 13.3. — Collaborative agents 

Negotiating Agents — Agents that negotiate with users or agents in a 

given environment to achieve an optimum outcome for their users or 

agents are classified as negotiating agents. 

Commerce Agents — Agents that participate and collaborate in commerce 

activities leading to transactions are categorized as commerce 

agents. Seller and buyer agents are good examples of commerce agents. 

• Seller Agents — Agents that represent sellers (e.g., suppliers and 

resellers) and automate their activities, such as tracking buyer demand, 

change in market dynamics, engage in competitive negotiations with 

buyer agents, perform knowledge mining and even learn through 

collaboration from buyer agents, are known as seller agents. 

• Buyer Agents — Agents that represent buyers (e.g., consumers and 

companies) and automate their activities, such as building and 

maintaining relationships with seller agents or users, engaging in 

competitive negotiations with seller agents, performing knowledge 

mining and even learning through collaboration with seller agents are 

known as buyer agents.

13.5. Agents and Autonomy 


Intelligence is based on autonomy. Autonomy refers to the ability of 

agents to take initiative, operate on their own and exercise some level 

of restraint and control on their own actions. Autonomy of the agents is 

driven by the following traits: 

• Goal-oriented — Autonomy is directly linked to the goal-oriented 

nature of agents. They should be able to learn and identify human 

needs and be responsible for pursuing a course of action to satisfy 

those needs. 

• Pro-activeness — Agents should act on their own instantaneously if 

and when they detect a change in their environment. This action 

should be chosen dynamically, based on the change. To do so, they 

would have to learn as they react and interact with their external 

environment. 

Effective adjustable autonomy minimizes the necessity for human 

interaction, but maximizes the capability for humans to interact at 

whatever level of control is most appropriate for any situation at any 

time. 

From the perspective of B2B e-commerce, adjustable autonomy 

(i.e., dynamically adjusting the level of autonomy of an agent) fits more 

as of the moment. There are several critical decisions that are involved 

in completing a B2B transaction successfully. With the given level of 

agent intelligence, humans should be involved at some level, based on 

the situation, to complete the transaction. 

13.6. Multi-Agent Environment 

A multi-agent environment consists of cooperating intelligent agents. 

In a multi-agent environment, there are multiple agents with different 

owners, users, skills, intelligence, constraints and governing rules. Agents 

in such systems have to interact, either in a selfish or cooperative way, 

both with associated users and other agents in their environments. The 

working of such environments is viable only with the coordination of 

the activities of multiple agents. Agents can develop the coordination 

strategies through learning and adaptation.


13.6.1. The 3 Cs of prime importance 

The 3 Cs of fundamental importance in a multi-agent environment are 

communication, collaboration and coordination. Individual agents operate 

with major knowledge and resource constraints to accomplish the given 

goal, making these three Cs a necessity in a multi-agent environment. 

13.6.2. Advantages of a multi-agent environment 

The advantages of a multi-agent environment are: 

• Modularity and Flexibility — A multi-agent architecture can be 

easily modularized. Different teams can work on different modules. 

The modularity and flexibility offered by a multi-agent environment 

makes it an invaluable tool to automate and implement concurrent 

B2B processes and practices, where there is no central control and 

high level of dynamics. 

• Information Sharing — Agents can share the information by communicating 

with other agents. 

• Efficient — Independent sub-tasks can be solved locally and speed 

can be increased as agents working on partial solutions can process 

complex instructions in parallel. 

• Multimode Input — Different modes of interaction can be integrated 

by the cooperation of agents. 

• Learning/Adaptability — An agent can learn the preferences and 

changing priorities of associated users. It can also learn about other 

agents in the multi-agent environment to compete or cooperate with 

them effectively. 

13.6.3. Disadvantages of a multi-agent environment 

The disadvantages of a multi-agent environment are: 

• Performance and Scalability — There are still several unresolved 

issues in multi-agent systems related to performance and scalability. 

Environment requirements, such as execution of several mobile agents 

simultaneously, slow down the system. Before adopting any specific


agent technology, companies should consider the performance and 

scalability of an agent system that requires communication and 

coordination with so many heterogeneous agents running on all kinds 

of platforms and systems over external networks like Wide Area 

Networks (WANs). 

• Security Risk — In a multi-agent environment, security risks are 

manifold as compared to stand-alone agents. 

• Unnecessary Interactions — In a large-scale multi-agent system, agents 

need to interact with other agents. There is the risk of an explosive 

number of unnecessary interactions that are futile in achieving agents' 

goals. 

• Unpredictable External Environment — As a multi-agent environment 

increases in scope, dynamics and complexity, the task of grasping its 

changes becomes more demanding. The unpredictability of changes 

or discontinuities up scales the environmental uncertainty. 

13.7. Agents and Negotiation 

The tremendous growth of B2B e-commerce has increased the importance 

and need for automated negotiation systems. Negotiation systems are 

built on a negotiation strategy and collaboration strategy. The goal of 

any negotiation strategy is to maximize outcomes within the boundaries 

and constraints of a given environment. 

In real world negotiations, humans take decisions based on their own 

expertise, past experience and in cooperation with other experts. How 

will the agents be able to replicate the human behavior counterparts? 

Let's first try to learn what we mean by a negotiation strategy in an 

agent's paradigm: 

1. Negotiation strategy is a formalized strategy responsible for computation 

of appropriate actions and outcomes. Negotiation protocols are 

established to govern and restrict the interaction among participating 

agents in a multi-agent environment. 

2. Negotiating agents have a goal that is associated with a set of 

parameters and binding rules with regard to penalty, commitment, 

recommitment, timeout and termination conditions. In a negotiation


process, a group of agents communicate with one another to come 

up with a mutually acceptable agreement. 

3. Design and implementation of any negotiating strategy and 

collaboration protocol isn't easy. A great deal of research still needs 

to be done, so that the negotiation strategy of any agent completely 

replicates human behavior. 

13.7.1. Types of negotiation strategies 

There are two fundamental types of negotiation strategy, as follows: 

Analytical Negotiation Strategies — They are based on static 

mathematical models to evaluate outcomes and generate corresponding 

actions. These strategies are usually reliable and stable in behavior. 

However, since they are static in nature, they tend to have a predictable 

outcome. 

Evolutionary Negotiation Strategies — They are dynamic in nature and 

adapt and evolve with time, learning by their behavior, environment and 

through other agents. However, they are extremely complex and very 

few implementations have been tried using such strategies. 

13.7.2. Not revealing negotiation strategy paramount 

If agents can somehow know what other agents are thinking and learn 

during their interactions how other agents behave, their payoff might 

increase. Learning in negotiation is tightly integrated with the issue of 

how to model the overall negotiation process, i.e., what negotiation 

protocols are adopted. 

It is very important for agents to hide their negotiation strategies. If 

the buyer agent knows the supplier agent's negotiation strategy (to 

accept all offers as long as they are above a certain threshold value), 

the buyer in this scenario can begin by offering a price lower than the 

threshold value and repeatedly offering the seller a penny more each 

time until the threshold value is reached. At this price, the supplier 

agent would accept the price, which is obviously not the optimum one 

from its perspective.

Client Application 

Hgrates 

Server Application 

II ] 

Cl ient Appl i cati on | 

i 

I 

Figure 13.4. — Mobile agent architecture 

13.8. Agents and Mobility 


Mobility is the ability of agents to migrate in a self-directed way from 

one host platform to another. Mobile agents are capable of migrating 

from one computer to another to execute a set of tasks on behalf of 

their owners (see Figure 13.4). These agents gather, filter and analyze 

data from multiple sources (nodes of the network) and present a subset 

of this data to another agent or owner. 

For example, a computer manufacturing company that needs semiconductor 

chips on a regular basis could have intelligent agents that 

monitor its internal inventory, usage forecasts and patterns and launch 

mobile purchasing agents when the inventory goes down. These agents 

would traverse different B2B e-marketplaces and suppliers and collect 

information about the chips based on specifications. They would then 

evaluate the prices, logistics, delivery date, etc. and make a decision 

about the supplier, negotiate the terms of the transaction, place orders 

and make secured automatic payments. At any stage, if agents feel that 

a human intervention is required, they will generate messages for users 

and notify them. 

13.8.1. Benefits of using mobile agents 

Asynchronous, adaptive and bandwidth-saving natures of mobile agents 

make them ideal for B2Bi. The main benefits of using mobile agents 

are:


• Mobile agents are dynamic in nature, i.e., they are able to adapt to 

new negotiation strategies and protocols, based on the current task. 

• Mobile code significantly reduces network traffic due to local agentto-agent 

communication. In a distributed application, like the ones 

supporting B2B e-commerce, network bandwidth is one of the major 

concerns. To successfully complete a single transaction in the B2B 

domain, applications of the companies concerned have to communicate 

a multiple number of times. In each communication there is a clientserver, 

round-trip involved which not only takes the already scarce 

network bandwidth, but also slows down the whole process, resulting 

in poor performance for the application as a whole. By creating a 

mobile agent to handle the query or transaction and sending the agent 

from the client to the server, network bandwidth consumption is 

reduced and the process becomes much faster. 

• Mobile agent architectures also solve the problem created by 

intermittent or unreliable network connections. In the conventional 

systems, if the network goes down, the whole transaction is aborted. 

The users of such applications have to redo all the work to complete 

the aborted transaction. In a mobile agent architecture, the client 

doesn't talk to the server over the network, instead, the client actually 

migrates to the server's machine. Once on the server's machine, the 

client makes its requests to the server directly. When the entire 

transaction is complete, the mobile agent returns home with the 

results. 

13.8.2. Potential risks involved in use of 

mobile agents 

Mobile agents have to expose their code and data to the host environment 

that supplies them the means to execute. Due to this feature, agents can 

be tampered with, scanned, or, in some extreme cases, even terminated 

by malicious servers. 

The risks of attack on an agent's activities and fitness are directly 

proportional to its mobility (see Figure 13.5). Thus, agents dealing with 

highly secured data, such as payment information, should be restricted 

in mobility.

Safety 

static 

--... 

mobile 


Figure 13.5. — Relationship between safety and mobility of software agents 

13.9. Agents' Role in B2B E-commerce and B2Bi 

The use of intelligent software agents that automate the coordination 

activities among business partners is not only an advantage, but a necessity 

in the connected and networked world that companies operate in. 

Intelligent agents can be responsible for collecting and interpreting 

information of merchants and products, making decisions, even presenting 

payment information and settling transactions, thus reducing time and 

cost. They will help buyers and suppliers achieve greater efficiencies in 

all of the important aspects of B2B, such as content, community and 

transaction. 

Additionally, agent based e-commerce happens on the Internet and 

does not require the high setup costs associated with EDI. Agent 

technology also leverages existing infrastructure and investments. 

Agents can help in automating all the repetitive activities in the 

following business aspects: 

• Internal functions and activities, such as accounting, order fulfillment 

and personnel management; 

• External activities, such as supply chain management and eprocurement, 

which involve interaction with trading partners, B2B 

exchanges; and 

• External customer centric activities such as eCRM, sales and services. 

Let us review these aspects in greater detail.


13.9.1. Information gathering and filtering 

In 1982, the volume of publicly available scientific, corporate and 

technical information had doubled every five years. By 1988, it had 

doubled every 2.2 years and by 1992 every 1.6 years. Due to the 

Internet, the amount of information available electronically has increased 

by manifolds and is now doubling in less than a year. According to 

IBM, over 67,000 corporations are publishing new Websites every day. 

This information overload is causing major problems, as far as 

gathering relevant information and network bandwidth are concerned. 

Information gathering and filtering agents help in overcoming these 

problems, as they affect B2B e-commerce and companies that participate 

in it, as follows: 

• Companies usually publish data such as catalogs in formats and 

structures that are vastly varied and this information is very dynamic. 

This information should be made available to all buyers just-in-time 

(JIT) — delivered immediately as needed, relevant — based on users' 

preferences and filters and auto-refreshed — updated whenever a new 

piece of information arrives. Agents can be used to locate information 

sources, to combine intelligently disparate streams of information 

from multiple distributed resources to respond to a specific request 

from users with relevant, synthesized results. Agents can help by 

managing data and information sources, such as routing e-mails, 

information retrieval, building dynamic catalogs and retrieving latest 

product information. In short, they are able to anticipate and act on 

users' information needs. 

• Companies face the challenge of organizing network flows in a way 

that prevents massive retrieval of information from remote sources. 

The inundation of data can cause severe degradation of their network 

performance. Software agents help in providing a solution to this 

problem. Agents can gather and select this information locally, thereby 

avoiding unnecessary network loads. 

• Agents are not only able to perform searches based on keywords, 

but also based on context. They will deduce this context from user 

information (i.e., a built-up user model) or by using other services,


such as a thesaurus service. With more efficient and powerful search 

capabilities, agents will help drive down e-commerce costs and make 

B2B e-commerce more transparent. 

13.9.2. Uncovering quality sales prospects 

Agents can automate the process of identifying quality sales leads for 

the sales and marketing professionals. They can search, retrieve, analyze, 

identify, generate precise targeted sales prospects and interact with 

users to develop an accurate data profile of a quality prospect in the 

target market segment. 

For example, ProspectMiner, a seller agent developed by Inkarta, 

generates buyer profiles by pulling information in parallel from 19 search 

and directory services. For each quality lead identified, ProspectMiner 

automatically researches the candidate company, retrieving and organizing 

the key information needed by sales and marketing professionals to 

initiate an informed contact. ProspectMiner can be set into auto-query 

mode to operate autonomously on the user's behalf, periodically scanning 

the Web for new prospects and information about previously identified 

and researched prospects in the given market segment. 

Advantages of Web-based lead generation include the ability to 

access far more companies than are available through any other lead 

source — finding the smallest, newest and least known prospects — and 

to retrieve the most current information about each quality candidate. 

13.9.3. Value chain integration 

An integrated supply chain allows businesses to share real-time 

information and drastically reduce transaction costs. Agents act as value 

chain integrators by automating and integrating the value chain. The 

value chain is comprised of inbound logistics, operations, outbound 

logistics, marketing and sales and service. 

Using agents that communicate and collaborate within the organization 

and with the trading partners, companies can reduce cycle times and 

increase transparency throughout the procurement and supply chain.


13.9.4. Optimization of business processes in 

light of B2Bi 

Agents enable companies to optimize their business processes and 

allocate the most qualified resources to perform activities in the shortest 

amount of time. By doing business more efficiently in conjunction with 

their value chain partners (e.g., order fulfillment, new product launch, 

contract negotiation and project management), companies can achieve 

significant cost savings. 

For example, Exterprise utilizes collaborative agent technology in its 

Agent-based Process Engine (APEx) to optimize business processes. 

EXTERPRISE'S APEX PLATFORM: 

POWERING COLLABORATIVE BUSINESS NETWORK 

Today's market conditions warrant fast change; frequently no two 

suppliers or channel partner relationships are the same. Also, business 

rules can vary from partner to partner. Exterprise utilizes collaborative 

agent technology in its Agent-based Process Engine (APEx) platform 

(see Figure 13.6) to bring together business process activities, business 

rules and resources at runtime. Exterprise customers report cost 

savings of 20% to 30% and higher. 

The APEx platform consists of a network of collaborative agents, 

'event-condition-action' driven programs designed to work continuously 

to complete a specific action. As their name implies, collaborative 

agents work together to solve a problem. Although each agent is 

autonomous, the resulting synergy from their cooperation makes the 

agents collaborative in problem solving. 

In an agent-based model, activities, rules and resources are 

independent of one another and are brought together at run-time. 

Thus, business processes adapt in real-time to varying conditions. 

Each process is highly configurable so companies can adapt and 

change as their businesses change. Processes are monitored as 

well, so each process can be examined and streamlined over time to 

maximize efficiencies. 


Q Once the process is 

requested, the process agent 

initiates negotiations with the 

pool of proxy agents having the 

capability to perform the rst 

activity of the process. 

© Selected'bestfit'proxy 

agent is assigned by the 

process agent to perform the 

activity. 

^7 Process agent communicates 

the specifications of the activity to 

the proxy agent. 

Q Proxy agent then begins work. 

Here is how agents function 

using an example process 

of building a home 

* ' 

While monitoring the progress of the 

process, the process agent repeats the 

negotiation and selection steps for 

subsequent activities until the entire 

project has been completed per the 

customer's specifications. 

* 

wans 

A 

* 

4PW 

A A 



Foundation ion _ sro&.#_ 

I Windows 

"ft 

* fl\ IHli 

I—A IP 

Figure 13.6. — Exterprise agent-based process engine 

APEx supports a number of pre-built collaborative processes in 

the system, such as contract management, complex matching and 

negotiations for sourcing, distributed order management and catalog 

product pricing management. 

Source: Exterprise.com 

13.9.5. Efficient e-marketplaces 

Almost all existing commercial B2B e-marketplaces provide limited 

services, such as communication supports between buyers and sellers,


industry news, liquidity and current market information and transaction 

services. 

KASBAH —AN AGENT BASED E-MARKETPLACE 

Kasbah is an agent marketplace that allows agents to negotiate the 

price of goods on behalf of consumers. However, Kasbah allows 

negotiations based only on price and uses only one specific negotiation 

strategy. 

In the Kasbah system, buyers who need to procure particular 

goods would create an agent, give it basic strategic direction and 

send it off into the electronic marketplace. The Kasbah agents would 

then proactively seek out potential sellers and negotiate with them on 

the buyer's behalf, making the best possible deal based on a set of 

constraints specified by the buyer, including the highest acceptable 

price and a transaction completion date. 

The selling agents in the Kasbah system are pro-active too. When 

a selling agent is created, the marketplace has to give it a list of 

potential buyer agents and inform all potential buyers of the existence 

of this new selling agent. It has to match up agents interested in the 

same goods. 

Using intelligent agents to buy and sell goods can create truly 

rational market behavior— just the way economics is supposed to 

work. Future exchanges will be built using a set of agents to support 

coordination, negotiation and settlement with both numerical data and 

textual information. Agents would automate the whole process of 

multidimensional B2B e-commerce involving product selection, payment 

methods, delivery, after sales service, etc. This is in sharp contrast to 

today's B2B e-marketplaces that are purelly transaction based. Such a 

multi-agent model would be ideal for highly uncertain and dynamic 

markets involving complex negotiation processes. The required conditions 

to build such a marketplace are the establishment of ontologies (in 

short: unequivocal definitions of entities) and protocols.


Agents can also act as intermediaries in B2B e-marketplaces by 

evaluating the quality of products, comparing prices and providing 

recommendations. 

13.9.6. Maintaining customer relationships 

Intelligent agents can automate the task of tracking customer behavior, 

linking business goals and customer interests, learning from previous 

experience, drawing conclusions from that and giving recommendations 

for actions to be taken due to changes in customer behavior. With the 

above information, suppliers can provide personalized service, such as 

sales suggestions, prices, bulk discounts and content to customers. 

13.9.7. Effective e-procurement 

Most of the activities involved in corporate procurement are defined, 

routine and repetitive in nature. But there is still a substantial human 

element involved in the procurement cycle, which slows the whole 

process down. Software agents automate the enterprise procurement 

process by finding and negotiating deals, instead of having personnel do 

it. According to a recent report from Deloitte Research, by 2002 

companies will routinely use intelligent agents to e-shop. 

Agents can assist buyers by finding all the products and their 

suppliers, based on a defined price, preferred highest acceptable, delivery 

date, delivery location and other defined specifications. Moreover, the 

decision-making capability of these buyer and seller agents is dynamic 

and reacts to user needs and the current environment. Agents like the 

ones used by commerceone.com (which hosts several vertical exchanges) 

assist in information sharing and aggregation between buyers and sellers 

across vertical and horizontal exchanges. 

Suppliers usually adopt a push strategy to announce their products 

and survey customer demand. Human sales representatives, who visit 

buyers on behalf of the supplier, traditionally carry out this task. Mobile 

software agents can automate this process quickly and with low cost by 

visiting many buyer sites, obviating much human involvement in the 

procurement process.


13.9.8. Integration with legacy systems 

Software agents provide an ideal mechanism for integrating legacy 

systems with new data systems. Agents are well suited to implement 

these middleware applications. They can be used to perform data translation 

and implement data systems interfaces that meet a wide variety 

of requirements. This is one of the key attributes of agent technology in 

automating B2B e-commerce, as dynamic B2B relationships involve 

exchange and interpretation of heterogeneous data. 

Agent technology can be used to produce a simple information agent 

by 'wrapping' any information source to allow it to conform to the 

communication conventions of an agent infrastructure. This allows for 

the interconnection and interoperation of multiple existing legacy systems. 

By building an agent wrapper around such systems, they can be 

interoperated into an agent society. 

13.9.9. Enable privacy in B2B transactions 

B2B e-commerce has delivered several benefits to businesses, but it has 

also substantially increased the need for privacy protection of participating 

companies. Any person or company should not own privacy. It 

should be a standard feature with every computer, every B2B transaction. 

With the help of privacy agents, businesses can automate and 

implement a privacy policy based on defined parameters. 

Privacy agents enable companies to: 

• Adopt and implement a privacy policy that takes into consideration 

the goals of a company's Website as well as the anxiety of consumers 

over sharing information online; 

• Give users choice and consent over how their personal information is 

used and shared; and 

• Put data security and access measures in place to safeguard, update 

and correct personally identifiable information. 

@YourCommand's unique intelligent agents that assure anonymity 

and privacy are an example of such agents.


HOW ©YOURCOMMAND'S SOLUTION WORKS 

©YourCommand is based on the model of an English butler who 

shops anonymously on behalf of a private person. The butler can 

be completely candid with a merchant concerning this person's 

needs, wants and preferences. The merchant benefits by knowing 

exactly what products are in demand. The private individual benefits 

by receiving the goods he or she wants through a trusted, 

private channel, without disclosing identity or any other personal 

information. 

@ YourCommand applies this model to electronic commerce, with 

the role of the butler played by an ©YourCommand intelligent agent, 

called a Tasklt. A consumer will be able to visit ©YourCommand's 

secure site and be completely candid concerning needs, wants and 

preferences — including price, style, location and other product 

attributes. A detailed demand profile — but not personal data — will 

be sent to merchants offering such products and those who can meet 

the demands can approach this consumer. Payment and delivery will 

also be completely anonymous. In short, the Tasklt agent protects the 

consumer's identity. 

The real-time demand data will allow merchants to mass-customize, 

maximize the consumer's shopping experience, thereby increasing 

their margins and sales. The same information can also be used to 

quantify lost sales. 

If the Tasklt does not find the item it is searching for, it continues 

a 'persistent search' of ©YourCommand's database. The search ends 

when the item is found or when the consumer calls off the search. 

In addition to benefiting consumers, persistent searches will create 

persistent demand that helps merchants tailor products and services 

to match this demand. ©YourCommand enables long-term relationships 

based on need and not identity and relieves merchants from 

the burden of having to collect and store personally identifiable 

information. 

Source: Condensed from How ©YourCommand Works, Business Wire


h 

Information j Matchmaking Matchmaking!, 1. _ . Information 

|"" Agent P ^ 

r ""'"""""* Agent f*** Agent f * Agent |^'»= J =»" r | 

,, ,, I Negotiating I Auctioning I Negotiating I „,,„_„ 

seller j»—» Agent p—» Agent f^ Agent I*** y 

Collaborative | Collaborative 

"* Agent ' Agent •* 

Figure 13.7. — Agent communication 

13.10. Need for a Universal Language 

In a multi-agent environment, interacting agents need to have the same 

understanding of a particular vocabulary and need to be able to present 

the data in a single consistent language. Agents within a system have to 

converse with agents external to the system, which are within another 

agent framework (see Figure 13.7). Dynamic communication, cooperation 

and collaboration among agents is possible only through a universal 

language like XML. In a previous chapter, we have already discussed 

the merits of using XML as a common syntactic representation of 

knowledge. 

Here are a few more merits of XML in the context of inter-agent 

communication: 

• XML has a way of defining the 'meaning' of new tags using XML 

itself. With XML, virtually any data anywhere can be adapted to the 

Web and used by agents. 

• XML enables communication, cooperation and collaboration among 

agents in a diverse, multi-agent environment (see Figure 13.8). 

• Cataloging and information gathering agents can monitor and retrieve 

online information from distributed and heterogeneous sources. This 

information represented in XML format can be analyzed on the fly 

and product catalogs and search results can be built dynamically. 

• Using XML, agents can be built on open standards. Assembling the 

various pieces of a complex multi-agent environment requires broad 

accessibility and interoperability, which is possible only if agents are 

developed using open standards.

Software 

Software Code 

XML Document 

Software 

Agent 

Software Code 

Exchange 

of XML 

XML Document 

Messages J"""*' 

Figure 13.8. — XML-based agent communication 


BRML: ENABLING COMMUNICATION AMONG 

DISPARATE AGENTS 

BRML (Business Rules for Electronic Commerce) is an 'XML Rule 

Interlingua for Agent Communication, based on Courteous/Ordinary 

Logic Programs'. It is used in connection with 'CommonRules' from 

IBM and was developed in connection with IBM's business rules for 

e-commerce project. 

CommonRules provides innovative XML interoperability and 

prioritized conflict handling capabilities. Using CommonRules, a seller 

Website or application can communicate its business policy rules 

about pricing, promotions, customer service provisions for refunds 

and cancellation, ordering lead-time and other contractual terms and 

conditions to a customer application/agent, even when the seller's 

rules are implemented using a different rule system to that in which 

the buyer's rules are implemented. The customer application/agent 

can then understand and assimilate those rules into its own business 

logic. Similarly, using CommonRules a customer can communicate 

with its suppliers RFQs/RFPs, including detailed conditions and 

policies expressed in rules, e.g., in supply chain settings. 

Source: IBM Corp. 

However, XML is only a 'grammar', i.e., a standard for how to use 

markup tags. It does not define any term or word in the language. In 

order for agents to communicate in a multi-agent environment over the 

Internet, there has to be a common vocabulary, which is available to 

and understood by all agents.


Is common vocabulary alone sufficient for agents to locate and 

communicate with each other? No. Agents need to know the addresses, 

locations and names of the remote agents in order to communicate with 

them. Extensible Name Service (XNS) maintains the dictionary and 

address book for Web agents. XNS provides a common vocabulary and 

a common global naming and addressing system for permanent linking 

of Web agents. 

13.10.1. XNS: A dictionary and address book for 

web agents 

The HTML linking mechanism for Web pages was based on Domain 

Name System (DNS), developed to name host computers on the Internet. 

But DNS names are far from ideal for naming Web agents, which 

represent more dynamic resources, such as people and businesses. 

Furthermore, Web agents need to be able to: a) move on a network (like 

people or businesses move locations) and b) change their names (like 

people or businesses change their names) — both without breaking their 

links with one another. For this reason Web agents needed something 

DNS was unable to provide: permanent, universal addresses. 

Software 

XNS Naming & 

Addressing System 

XNS Name: Evan 

XNS ID: 10000 

XNS Address: 

78.202.15.3 XNS Link 

(10000 

to 20000) 

XNS Name: Ben 

XNS ID: 20000 

XNS Address: 

80.187,13,2 

Figure 13.9. — XNS naming and addressing system linking web agents


The developers of Web agent technology recognized that they could 

solve both problems at once — create a global Web agent vocabulary 

and a global Web agent naming and addressing system — by designing 

a new Internet name service based on XML (see Figure 13.9). Thus 

Extensible Name Service (XNS) was born. In short, XNS is to DNS 

what XML is to HTML. 


Current trends have made it clear that the complexity of B2B ecommerce 

and the software that enables it will increase dramatically in 

the coming decades. The focus has to be on infrastructure, negotiation, 

information gathering and transactional technology to ensure a smooth 

transaction from proper goods selection to final payment and goods 

delivery. 

Intelligent agents are the most promising paradigm for facing these 

challenges, overcoming the difficulties and exploiting the opportunities 

associated with B2B e-commerce. 

However, if intelligent agent technology is going to survive, it has to 

be able to deal effectively with the most important characteristics of 

B2B e-commerce: global business and information infrastructure. B2B 

e-commerce is very dynamic, large, distributed, heterogeneous, open 

and constantly evolving. The dynamic and distributed nature of both 

data and applications require that software agents not merely respond to 

requests for information but intelligently anticipate, adapt and actively 

seek ways to support users. Intelligent systems should not only assist in 

coordinating tasks among humans, they must also communicate, cooperate 

and collaborate among distributed programs. 

In the long-term, agents will approximate true 'smartness', in that 

they can collaborate and learn, in addition to being autonomous in their 

settings. They will possess rich negotiation skills and some may 

demonstrate what may be referred to, arguably, as 'emotions'.


Part IV 

B2Bi-Enabled Applications 

407


Chapter "| 4 

Supply Chain Management (SCM) 


Supply chain management (SCM) is one of the most important 

applications enabled by B2B integration for various industries. B2Bi 

helps businesses effectively Web-enable all processes of supply chain 

management and allows tight integration with processes of customers, 

suppliers, distributors and marketplaces. 

In this chapter, we have presented the fundamentals of SCM, along 

with an in-depth discussion of how B2Bi automates it. You will learn 

about the differences between a push and a pull-based supply chain, 

challenges involved in implementing a supply chain management solution, 

different SCM techniques and features of SCM systems. 

409



B2B integration opens a world of opportunities for effective and 

successful supply chain management which coordinates and integrates 

all activities, internal and external, into a seamless process. The internal 

activities pertain to various departments within an organization and 

external activities relate to trading partners, such as vendors, carriers 

and third-party companies. A company that is able to automate all 

activities through B2Bi is in a position to deliver products with low 

operational costs and high profitability and would stand the market 

competition and flourish. 

B2Bi helps businesses effectively Web-enable all processes of supply 

chain management and allows tight integration with processes of 

customers, suppliers and marketplaces. 

14.2. Fundamentals of Supply Chain Management 

In this section we will go over some of the fundamentals of SCM. SCM 

is a subject in itself, thus it is not possible to cover each section 

in-depth. Our goal is to provide differentiation between a B2Bi-enabled 

and a legacy supply chain. 

14.2.1. A few definitions of SCM 

There are numerous definitions of SCM. Here are a few of them: 

• SCM is the process of maximizing a company's internal practices 

and its interaction with suppliers and customers, in order to bring 

products into market more efficiently. 

• SCM is a business strategy to strengthen the shareholder and customer 

value by optimizing the flow of products, services and related 

information from point of origin (source) to the end user. 

• SCM enfolds processes of creating and fulfilling the demand for 

goods and services. 

• SCM is a set of business processes that covers a trading partner 

community engaged in a common goal of gratifying the end customer.

Supply Chain Management (SCM) 411 

SCM includes a large variety of functions such as demand forecasting, 

locating the sources of procurement, inventory and warehouse 

management, production scheduling, processing of orders, distribution 

logistics, customer service and other disciplines. All these functions are 

automated through the use of advanced software application called the 

SCM system. 

14.2.2. What is a supply chain? 

A supply chain is a network of facilities and distribution operations that 

procures materials and transforms these materials into intermediate and 

finished products and finally distributes them to customers. It is an endto-end 

chain with transparency and visibility, which enfolds all suppliers 

— main and sub-suppliers — internal operations, customers, both trade 

and retail ones and all other end users. All interlinked resources and 

activities needed to create and deliver products cum services to customers 

constitute a supply chain. This chain exists in manufacturing organizations 

and services, though its intricacies may differ substantially from industryto-industry 

or company-to-company. 

In a supply chain, every customer is a supplier to the next customer 

until the finished product reaches the ultimate end consumer. 

Example of a supply chain 

Before probing into the details of a supply chain, it would be worthwhile 

to bring under focus the relationship among trading partners in a supply 

chain by analyzing the example of manufacturing and distribution of 

cereal. 

The whole process starts with farmers sowing, growing and harvesting 

grains. So, it is the farmer who puts the process into motion initially. 

Companies buy grains from farmers and process the same into cereals 

which are packaged into boxes. The boxes in turn are transported to 

various distributors for sale to grocers with end consumers eventually 

purchasing the cereal boxes. 

Various interrelated processes and relationships among trading partners 

of a supply chain, as shown in Figure 14.1, together form a supply chain.


Grain Cereal 

Processing &. 

Manufacturing Packaging 

Facility 

Label Producer 

Packaged Cereal 

Figure 14.1. — Example of a supply chain 

M M 1M 

Retailer le ^sterner 

(Final Consumer) 

Requisition Supervisor 

Purchasing 

. Senior Manager 

Agent K 

n 

Acknowle 

Purchase 

dgment 

Order 

Central 

Receiving 

Shipment M- Supplier 

Recei pt 

V 

Accounts 

Payable 

-• Check/Payment Bank 

Figure 14.2. — Business process and workflow of a purchase requisition 

14.2.3. A typical business process flow in a 

supply chain 

A supply chain flow extends from the original materials suppliers 

through manufacturing, wholesaling and retailing to the final consumer. 

Figure 14.2 shows the entire business process and the workflow of a 

purchase requisition in a company. 

Whenever there is a purchase requisition in a department, it is 

forwarded through the supervisor to the senior manager who, after


review, passes it on to the purchasing agent for procurement. The 

purchasing agent then contacts the appropriate supplier from the approved 

list of suppliers, considers various factors such as competitive rates, 

quality, quantity available and lead-time and then issues a purchase 

order to the supplier. 

The supplier acknowledges the purchase order, giving details including 

the date of shipment and mode of transport. The purchasing company 

warehouse receives the goods in due time and after proper verification, 

delivers the same to the requisitioner and reports the delivery and 

acceptance of goods to the accounts department. Simultaneously, the 

supplier also sends the accounts department the invoice for the goods 

shipped and accepted by the warehouse. The accounts department 

then issues instructions to the bank for payment in accordance with the 

terms of payment agreed upon with the supplier or as mentioned in the 

purchase order. 

14.2.4. Activities in a supply chain 

A supply chain involves three-tier activity (see Figure 14.3): 

• Upstream activities; 

• Internal activities; and 

• Downstream activities. 

Upstream activities 

The first part of a supply chain involves activities, such as material and 

service inputs of upstream external suppliers who provide raw materials, 

component parts, end products, services, infrastructure support and 

computer technology. 

While most companies rely on one level of suppliers, manufacturers 

depend upon a complex hierarchy of suppliers in their supply chains. The 

number of suppliers involved in a manufacturing process is much larger 

than in any other sector as the product produced tends to be more 

complex. For example, a typical automobile manufacturer may depend 

on 60,000 to 100,000 suppliers, due to the requirement of enormous 

number of parts which make up the end product. As the products are


?*Tier 

Suppliers 

Upstream 

Internal 

Downstream 

2" Tier 

Suppliers 

l**Tier I 1" Tier 

Suppliers I Suppliers 

Assembly/ 

Manufacturing 

& Packaging 

I 

Distribution 

Centers 

Ret; ilers 

4 

Customers 

2"" Tier 

Suppliers 

Figure 14.3. — Supply chain activities 

linked to raw materials, manufacturers are linked with their suppliers' 

information systems for their inventory and replenishment and other 

issues which are directly relevant to the manufacturing process. 

Internal activities 

Internal activities involve the conversion of raw material procured from 

suppliers into finished product. These are processes to convert raw 

material procured from the suppliers into finished product. The 

synchronization of various internal activities at different levels has to be 

very agile and harmonious, especially in a big organization. Different 

functions, such as production planning, demand forecasting, manu 

facturing, order processing, packing of goods and maintenance, need 

the utmost care and vigilance.

Downstream activities 


Last but not least, downstream activities of a supply chain involve the 

distribution of the finished product to the distributors for sale to the end 

consumers. In the downstream activities, logistics function plays a vital 

role. It includes transportation management — selecting and managing 

the internal and external fleet of carriers, packaging, warehousing and 

handling of finished products at the warehouses and retail outlets 

receiving them. All these activities are integral and need strong links 

with one another to maintain the flow of supplies unobtrusively. 

14.3. Legacy Supply Chain 

Let's review the definition and limitations of a legacy supply chain. 

14.3.1. Push-based supply network 

A legacy supply chain is primarily forecast driven, which relies on 

push-based supply network for the procurement of materials. 

In a push-based supply network, the materials department procures, 

based on the marketing forecasts; the production department produces, 

based on the production cycle demand; and the distribution department 

distributes according to the replenishment demand (see Figure 14.4). A 

forecast is after all based on expectations, subject to various factors in 

the market. This may be faulty, as the gap in the expected and the real 

may lead to accumulated inventories or shortage of materials. 

Materials 

Supply 

Campaign 

Demand 

Production Distribution Consumption 

Production 

Demand 

Push 

Repl eni shm ent 

Demand 

Figure 14.4. — Push-based supply chain 

Consumer 

Demand


14.3.2. What's wrong in a legacy supply chain? 

A legacy supply chain appears very simple since it gives one the 

impression of being smooth without any obstructions and accumulations 

of inventories at different levels with various supply chain partners. As 

reflected in Figure 14.5, it appears to have very few links and barriers. 

Raw Material 

• • j 

•Ji 


(Final Consumer) Retailer 

Supplier Manufacturer 

Figure 14.5. — Superficial picture of a supply chain 

*rFiir 

Raw Material Warehouse 

• • 

Hi Customer 

(Final Consumer) 

TBBH 

Supplier Warehouse 

yw 

Retailer 

lite 

Warehouse 

—* Warehouse 

la 

Figure 14.6. — The real picture of a supply chain 

Manufacturer 

irtL 

Warehouse 

l(t 

Warehouse 

• 

Distributor


However, the real picture is far more ugly and intricate than what 

it appears to be. A legacy supply chain is crowded and congested 

with unnecessary steps and superficial stockpiles. There are a number 

of barriers and steps inherent in a legacy supply chain as shown in 

Figure 14.6. 

Lack of external collaboration 

A legacy supply chain has a high degree of demand uncertainty and 

variability. The forecast figures in a legacy supply chain are not shared 

dynamically by supply chain partners, resulting in each of them having 

a buffer stock or unnecessary inventory at multiple steps in various 

warehouses. 

In addition, it takes a long time for the finished product to cross all 

the barriers of the supply chain and ultimately reach the consumer. 

Lack of internal collaboration 

In a legacy supply chain, the focus is on task specialization and local 

optimization of functions rather than performance of an organization as 

a whole. The internal departments have their own objectives which may 

often conflict. 

Various departments in an organization engaged in different activities, 

such as planning, purchasing, manufacturing, distributing and marketing 

have tended to work independently in the supply chain. All these 

departments have different priorities. The result is that there is not a 

single, integrated plan for an organization — there are as many plans as 

there are departments. 

14.4. B2Bi-Enabled Supply Chain 

There is an imperative necessity for a mechanism through which different 

internal and external departmental functions can be integrated together. 

B2Bi allows the creation of a supply chain that involves greater 

integration, collaboration and exchange of information with its suppliers 

and customers. Such a supply chain is based purely on pull-based supply 

networks.


Let's review principles of a good supply chain before we discuss the 

pull-based supply chain, which is based on them. 

14.4.1. Principles of SCM 

Accenture, a leading provider of technology and management services 

and solutions, has laid down a few principles of effective supply chain 

management. If these principles are adopted, it gives a company 

competitive advantages over others in the form of larger revenues, 

tighter cost control, more effective asset utilization and better customer 

service. 

The principles spelt out are as follows: 

1. Division of customers based on service needs — Prior to the 

introduction of SCM, customers were provided with the same level 

of services within a group after classifying them by industry, product, 

or trade channel. An effective SCM, however, groups customers by 

their diverse service needs, irrespective of the industry they belong 

to, and then customizes services to suit these groups. 

2. Tailor the logistics network — A successful SCM is not based on a 

large logistics network but rather caters to the service requirement 

bottom-line needs of customers. 

3. Listen to signals of market demand and plan accordingly — A 

successful SCM senses and reacts to changing market conditions, 

such as demand patterns of customers, through its sales and operations 

planning module. 

4. Distinguish products that the customer wants — Gone are the days 

when companies could stockpile their products in anticipation of 

demand and make customers keep large inventories. There has now 

been an appreciable change in the balance of power between customers 

and companies providing them with products and services. Now it is 

the customer who is in the driving seat, asking companies to deliver 

what, when and how. 

5. Strategic management of supply sources — The real-time information 

sharing enabled by SCM helps companies to reduce their inventory, 

thereby lowering the operational costs.


6. Using technology across supply chain — A successful SCM is 

built on strong foundation of information technology which enables 

real-time information sharing and a transparent and dynamic view of 

flow of products among trading partners. 

7. Measuring performance through the supply chain — SCM not 

only monitors the internal functions, it also enforces measures which 

embrace both service and financial metrics, to every link in the 

supply chain. 

14.4.2. Pull-based supply network 

The redesigned pull-based supply network is demand oriented and 

highly efficient. Since actual consumption pulls the distribution, which 

in turn guides the production and the material procurement. This paves 

way for smooth replenishment, production and material supply with 

consumer and retail demands. 

For proper assessment and forecasting of the demand, all partners 

in this chain must involve themselves. This chain works backwards, 

beginning with the customer and makes the forecast for products and 

the production runs (see Figure 14.7). 

The future belongs to tightly integrated supply chains running from 

raw-material suppliers to the consumer, with information flowing front 

to back and back to front. 

Consumption Distribution K 

Consumer Retail 

Demand 

Syncronized 

Replenishment 

Production 

Pull 

Syncronized 

Production 

Figure 14.7. — Pull-based supply chain 

Materials 

Supply 

Syncronized 

Material Supply


14.4.3. ROI in moving from pull-based to push-based 

supply network 

Worldwide studies have revealed that in various companies there has 

been a 20-50% improvement in overall working capital, capacity 

utilization, cost of goods and customer service with a pull-based supply 

network, as compared to push-based supply network. Additionally, 

improvement in the time to market has been registered at 50-100%, 

resulting in a corresponding 3-15% increase in the market share. 

14.4.4. Features of B2Bi-enabled supply chain 

The key features of B2Bi-enabled supply chain are collaboration, 

integration and data exchange (see Figure 14.8). 

Collaboration 

Collaboration can make a world of difference between a performing and 

non-performing supply chain. Opportunities for collaboration exist at 

every link in the supply chain. Through a collaborative business process, 

problems of potential and frequent discontinuity at all interfaces of a 

supply chain (i.e., designing, planning, forecasting and execution) can 

be avoided. 

Coll abo rats 

Figure 14.8. — Feature of B2Bi-enabled supply chain


For instance, determining the level of production and inventory 

required to meet the end customer demand is a critical function. In a 

collaborated supply chain, buyers and suppliers work jointly to derive 

sales forecast figures by sharing demand and supply forecasts and 

building production plans, based on that consolidated number. 

Collaboration requires sharing real-time information on: 

• Production schedules; 

• Design and fulfillment; 

• Procurement; 

• On-hand and in-transit inventory; 

• Demand forecasts and supply management; and 

• Manufacturing capacities. 


The SCM system of a company is functionally very closely linked to 

the ERP and CRM system (see Figure 14.9). A B2Bi-enabled supply 

Supplier 

Relationship 

Management 

Material 

Management 

Procurement 

Manufacturing 

Enterprise Resource Planning 

Production Fulfillment 

Warehouse 

Management 

Transportation 

Management 

Inventory 

Management 

Enterprise Resource Planning 

Supply Chain Management 

Customer Relationship Management 

Order 

Management 

Distribution 

Logistics 

jj Sales 

:< Service 

: I Marketing 


Relationship 

Management 

Figure 14.9. — Relationship of SCM, ERP and CRM systems


chain involves cross-organization and internal process synchronization, 

integration of SCM system with CRM, ERP and legacy systems of a 

company and integration with the SCM system of other companies. A 

B2Bi-enabled supply chain is fully integrated end-to-end. 

Data exchange 

A B2Bi-enabled supply chain involves real-time and synchronous 

exchange of information among the trading partners' SCM systems. 

14.5. Supply Chain Planning and Execution 

The processes within SCM have been grouped together into a couple of 

sub-processes, namely supply chain planning and supply chain execution 

(see Figure 14.10), which are further composed of several sub-processes 

(see Table 14.1). 

14.5.1. Supply chain planning (SCP) 

Supply chain planning is a set of processes that allow business partners 

to collaborate and coordinate activities, such as planning, forecasting 

f 

Supply Chain Planning 

Information Flow 

ftt 

I liD Flow S 3 Flow tWB Fiow < jWH > Flow IllBI 

Supplier Manufacturing Distribution Retailer Customer 

(Final 

Consumer) 

f \ 

Payment Flow 

Supply Chain Execution 

Figure 14.10. — Supply chain planning and supply chain execution processes


and replenshing throughout the supply chain, thereby accelerating the 

delivery of goods, services and information from supplier to customer 

and balancing supply and demand. SCP processes optimize the flow 

of information, material and cash across the extended supply chain. 

SCP is composed of sub-processes, including demand forecasting, 

inventory data, production planning and distribution, order management, 

transportation planning or logistics and scheduling. 

Companies that participate in SCP reduce excess inventory, improve 

inventory velocity and increase sales throughout the supply chain. 

Example sub-processes 

Demand Planning — Demand planning, a process which feeds into the 

supply planning process and demand fulfillment process, allows for 

effective anticipation of market demand. The objective behind this 

process is to analyze customers' buying patterns and develop aggregate 

and collaborative forecasts involving long-term, intermediate-term and 

short-term time horizons. 

Supply Planning — Supply planning helps in mobilizing the resources 

of an enterprise to meet demand. 

14.5.2. Supply chain execution (SCE) 

Supply chain execution is a framework of execution-oriented applications 

which helps in the efficient procurement and supply of goods, services 

and information across enterprise boundaries to meet specific customer 

demands, including manufacturing execution systems, warehousing 

management systems, procurement and other execution systems within 

an enterprise and across the supply chain. 

Example sub-process 

Demand Fulfillment — Demand fulfillment provides accelerated, exact 

and reliable delivery-date responses to customer orders. It is mainly an 

execution-level sub-process that includes order procurement, customer 

verification, order promising, backlog management and order fulfillment.


Table 14.1. Supply chain processes and sub-processes 

Process 

Supply Chain Planning 

Supply Chain Execution 

Sub-processes 

Order Management 

Advanced Scheduling and Manufacturing Planning 

Demand Planning 

Supply Planning 

Distribution Planning 

Transportation Planning or Logistics 

Procurement 

Replenishment 

Demand Fulfillment 

Distribution Management 

Reverse Distribution or Reverse Logistics 

Each of these processes is a subject in itself and books can be 

written on each one of them. We will briefly discuss a couple of 

important processes of a supply chain in the next section. 

14.5.3. E-procurement — The transformation of 

corporate purchasing 

Procurement of raw materials and finished goods is one of the most 

important functions in a supply chain. Most companies still use manual 

purchasing processes that involve much paperwork and are inefficient 

and error-prone. Such purchasing processes are characterized by lack of 

automation, zero transparency and huge purchasing overheads. 

E-procurement is the process of procuring goods over the Internet, 

using an integrated supply chain (see Figure 14.11). E-procurement 

has emerged as one of the strongest and most financially beneficial 

B2Bi-enabled applications. 

An e-procurement solution allows companies to leverage their buying 

power, strengthen their supplier relationships and streamline internal 

purchasing processes. By automating procurement processes, companies 

eliminate any unplanned buying, reduce administrative overheads and 

eliminate all the paperwork.

vJ 



II 11 II II 

CXML 

Internet 

E-marketplace 

| E-marketplace 

1 

T Tl 


Figure 14.11. A typical e-procurement cycle 




Automation not only reduces errors, but also makes information 

available on a real-time basis, thereby streamlining corporate purchasing 

policies. Instead of manually browsing through all the brochures to 

order a specific item, a company can get that information pushed 

electronically over the Internet. The gains are significant and available 

across the whole spectrum of an organization's purchasing. 

Numerous companies such as Ariba (Ariba Buyer), Agile Software 

Corp (Agile Buyer), Extensity (Extensity Purchase Reqs), i2 Technologies 

(TradeMatrix Buy Solution), J.D. Edwards (JDEdwards E-procurement), 

SAP (SAP Enterprise Buyer), PeopleSoft (PeopleSoft E-procurement 

and Purchasing), Peregrine Systems (Get.Resources), Commerce One 

(Enterprise Buyer), BroadVision (Enterprise Procurement provide 

e-procurement solutions.


An e-procurement solution should include features for desktop 

requisitioning, automated processing, indirect purchasing, direct and 

indirect sourcing, travel and expense management and electronic forms. 

It should streamline accounts payable systems; enable easy transition 

from a paper-based contract management system to an electronic one, 

procurement of requisition and project-based resources, aggregation 

with service suppliers and optimization of business processes; provide 

access to centralized commerce services, such as supplier content, 

sourcing, liquidation, logistics and payment; deliver an open architecture 

that allows buying organizations to connect with thousands of trading 

partners worldwide; and track requisitions allowing end users immediate 

visibility into the procurement process. Once integrated into a company's 

infrastructure, the solution should enable connectivity with any number 

of e-marketplaces and collaborative networks. This feature is only 

possible if the solution is based on open standards and architecture. 

GET ON TO THE FAST, EFFICIENT TRACK WITH 

E-PROCUREMENT 

A recent American Express and Ernst & Young study revealed that 

firms using manual purchase orders to buy low-dollar supplies and 

services incur an average process cost of $90 for each transaction, 

with some organizations spending as much as $200 on certain 

transactions. In comparison, the study indicated that companies using 

e-procurement systems incurred significantly lower processing costs 

of $20 to $45 per purchase. 

Better still, firms that employed purchasing cards for payment and 

accounting tasks with electronic procurement systems to buy supplies 

reduce their process costs to as low as $4 per purchase, a decrease 

of 95%. In addition, companies can cut the time required for the 

purchasing process from two hours to 7.4 minutes by using a combined 

purchasing card and electronic purchasing solution. 

Source: Condensed from eProcurement: End-to-end Solutions Deliver Big Cost 

Savings, Alliente, Inc.


14.5.4. E-logistics: Integrating warehouses, distribution 

centers and customer interaction processes 

Most companies still use manual methods, spreadsheets, or proprietary 

software to manage their logistics processes (i.e., transportation and 

distribution activities). 

Assets stored in a warehouse are fairly easy to track. However, these 

same assets become almost invisible and very difficult to track when 

they are in transit. In today's competitive business environment, where 

business competitors can outbeat a company with effective implementation 

of just-in-time (JIT) delivery, a company cannot afford to lose track 

of its assets. Companies need to implement a fast-moving, adaptable 

logistics system for everything from purchasing through manufacturing 

to sales and distribution of goods and services. 

E-logistics essentially consists of Internet-based management and 

integration of warehousing, delivery and transportation, return management, 

order management and customer interaction processes across 

all vendors and customers. Customer interaction usually involves order 

status, various delivery calls (urgent delivery, pick-up delivery, overnight 

delivery). 

The e-logistics solution should standardize transaction management 

and logistics processes of a company and integrate them into the 

company's internal transaction infrastructure. It should provide realtime 

visibility and performance monitoring of movements of goods and 

events and enable Internet-based collaborative capacity planning, load 

tendering, carrier availability notifications, inventory status reporting 

and proof-of-delivery validation. The e-logistics solution should also 

enable real-time communication between the dispatching company and 

carriers, giving carriers the ability to dynamically perform tasks, such 

as sales automation, delivery verification and route sales. Furthermore, 

it should enable the dynamic optimization of routes and vehicle dispatch 

by giving companies the ability to monitor and update real-time delivery 

status. 

Software providers such as Descartes Systems, i2, SAP, PeopleSoft, 

Baan offer a Web-based collaborative logistics management system.


14.6. SCM Challenges 

No doubt the concept of integrated supply chain management is prima 

facie alluring but one cannot be blind to the enormous difficulties 

accompanying the implementation of such a strategy. 

A few of the major challenges companies encounter in SCM 

implementation are: 

14.6.1. Synchronization in supply chain 

Getting suppliers in tune and time with the pace manufacturers maintain 

is a threatening challenge facing SCM. Trading partners, with their 

individual priorities, pursue different processes and practices. Subject to 

individual factors, one may take a longer or shorter time than others for 

the same process. Synchronization with all on the time scale is rather a 

difficult task. 

14.6.2. Building trust through supply chain 

The creation, implementation and functioning of a supply chain is not 

possible without the trust among the organizations and departments 

participating in it. Without trust, there can be no visibility, which is a 

key feature of any supply chain system. Lack of visibility in the trading 

partners activities and capabilities may entail increased risk in terms of 

cost and time, various stages of relationships, identifying constraints 

and the ability to manage bottlenecks. 

14.6.3. Operational stability 

The success of a supply chain is directly dependent on its operational 

stability. If one supplier in the chain of suppliers fails to deliver, a chain 

reaction could potentially disrupt the business of any company connected 

to the chain. Thus, the challenge for manufacturers relying on supply 

chains is to maintain operational stability by ensuring supply chain 

continuity.

14.6.4. Inertia for change 


It is not an easy task for people and organizations as a whole to change 

age-old business practices. The fear of complete automation leading to 

the removal of human intervention may be a big deterrent factor in the 

acceptance of this change. 

14.6.5. Supply chain complexity 

A supply chain is beset with baffling intricacies. It may take a long 

time to attain and enjoy the fruits of transformation by adopting changes 

in policies, processes and patterns required by the application of a 

supply chain. Re-engineering the fundamental processes and bringing in 

new procedures may require more user training and consulting. 

14.6.6. Managing supply chain for short 

lifecycle products 

In the case of a product with short expiry period or lifecycle, the challenge 

lies in maintaining the product availability at the counter while keeping 

the dead stocks as low as possible. It also requires greater skill in 

monitoring the short-life products than the long-life products because: 

• It is not easy to anticipate the demand figures due to demand patterns 

and variables; 

• In the traditional forecast method, the demand for any product was 

worked out on the basis of one year's data, which is not possible in 

the case of products having a lifecycle of less than a year; and 

• With expired leftover stock, the cost of inventory in the form of dead 

stock is higher rather. 

It is critical to forecast the demand correctly and make swift changes 

if the market conditions fluctuate. 

14.6.7. Integration challenge within the organization 

Multiple departments are involved in the movement and storage of 

goods. For example, the purchase department takes care of procurement


of raw materials and transportation of raw materials to the production 

plant. Storage and movement of products within the plant itself are 

taken care of by the stores department (in the stores) and by the 

manufacturing department (in the plant). The distribution department 

is responsible for the movement of finished products from the plant 

to the customer while the marketing department works out the sales 

predictions. 

Flow of information within all the departments concerned in many 

cases is not smooth and timely. Although SCM aims to integrate these 

functional departments within an organization, the fact is that it is a 

daunting effort. 

14.6.8. Integration challenge with supply 

chain partners 

The enormous heterogeneity makes transition from an enterprise strategy 

to a supply chain system quite challenging. The most difficult facet in 

implementation is linking trading partners because it needs systems to 

reconcile disparate business models, data contexts and notions. 

14.6.9. Inter-company business 

process synchronization 

Reluctance and resistance of chain partners to share information and 

switch over their respective business processes may be the greatest 

stumbling block. The reasons for hesitation may be manifold, e.g., lack 

of faith, unwillingness to change the long existing business processes 

and apprehension regarding secrecy. 

14.7. SCM Techniques 

Methodologies for implementing an SCM solution within an enterprise 

include Quick Response, Vendor Managed Inventory, Just-in-time, 

Collaborative Planning Forecasting and Replenishment and Collaborative 

Order Processing. 

Here is a brief summary of some of the major techniques:

14.7.1. Vendor Managed Inventory (VMI) 


VMI is a framework that streamlines the approach to inventory and order 

fulfillment leading to minimum level of inventory and reduced operational 

costs. In this system, the responsibility of managing and replenishing 

inventory is shifted from retailers to the suppliers. In a VMI system, 

vendors keep track of the number of products supplied to distributors 

and retail outlets. It keeps them abreast of the requirements of distributors 

and stocks at the counter outlets enabling them to replenish them timely. 

14.7.2. Just-in-Time (JIT) 

JIT is defined as an integrated set of multiple activities with a view 

to achieving high-volume and best quality production with minimum 

inventory levels. It aims at reducing inventories by collaborating and 

coordinating with suppliers of materials for delivery just before their 

use, thereby reducing inventory-carrying costs. 

The JIT model works on the concept that unless actually needed, 

nothing will be supplied. In other words, raw materials and components 

reach the workstations just-in-time and are put through the manufacturing 

process immediately thereafter. It takes into cognicance changes in 

supply and demand portfolios. 

Since JIT is based on almost real-time delivery of raw materials, it is 

subject to great reliance of the company on suppliers, transportation and 

delivery of raw materials and components at the specified destination, 

on tight schedules. Any break in the link anywhere may cause disruption 

and bring the production to a standstill, paralyzing the entire chain from 

manufacture to supply. 

Companies are now switching to Internet-based technologies to 

establish an electronic dialogue with their suppliers, making the JIT 

ordering and delivery process faster and more flexible. 

14.7.3. Collaborative Planning, Forecasting and 

Replenishment (CPFR) 

CPFR is a standards-based, collaborative, e-commerce initiative in the 

retail and consumer goods industry. CPFR aims to improve partnership


among retailers and vendor merchants through shared information. It 

integrates both 'demand' and 'supply' side processes (linking manufacturers, 

retailers and carriers) and improves the flow of a product and 

information about the product throughout the entire supply chain. 

Increased communication among partners enables them to generate 

accurate forecasts and set effective replenishment plans. Additionally, if 

there is any change in demand, promotions or policies, partners can 

quickly adjust the jointly managed forecasts, thereby minimizing the 

wasteful inventory after the fact corrections. 

CPFR is a concept that allows collaborative processes across the 

supply chain, using a set of process and technology models that are: 

• Open and secured; 

• Flexible across the industry; 

• Extensible to all supply chain processes; and 

• Supportive of a broad set of requirements (new data types, 

interoperability with different DBMSs, etc.). 

Introduction 

NABISCO AND WEGMANS — CPFR PILOT 

OVERVIEWS WITH METRICS 

Nabisco is a major international manufacturer of biscuits, snacks, and 

premium grocery products, including well-known U.S. brands Oreo, 

Ritz crackers and Planters nuts and snacks. It also manufactures 

international products, which are marketed in the United States, 

Canada and 85 other countries. 

Wegmans Food Markets, Inc. is a 58-store supermarket chain in 

New York and Pennsylvania and is recognized as an industry leader 

and innovator. 

Executive Summary 

Category management and supply chain management have been proven 

to offer a competitive advantage to firms that can successfully 

implement them. 




Trading partners can gain an even greater advantage by linking 

these activities through the CPFR (Collaborative Planning, Forecasting 

and Replenishment) process. CPFR provides the opportunity to link 

the output of business plans that were jointly developed between 

trading partners into the supply-chain process. 

The business plans and forecasts are monitored and kept current 

by both trading partners by the creation of a two-way interactive 

communication process. These activities can help increase sales and 

profits between participating partners. 

Scope 

Nabisco and Wegmans engaged in a CPFR pilot to validate the VICS 

(Voluntary Inter-industry Commerce Standards) business model. The 

pilot was limited to 22 Planters nut items. The pilot was conducted 

without increasing resources in the area of headcount or technology. 

For the first six months, transfer of information was accomplished 

using spreadsheets and e-mail. 

Metric Results 

Actual results from the CPFR pilot from July 1998 through January 

1999 include: 

• An increase in category sales by 13% vs. 8% decline for other 

retailers in the market; 

• Sales increases for the Planters brand were especially dramatic at 

53%, as measured by IRI for 30 weeks ending January 17, 1999; and 

• The majority of the increases in retail sales can be attributed to 

jointly developed business plans that leveraged enhanced category 

management strategy and increased category focus. 

These results were achieved with minimal stress on the supply 

chain due to CPFR. 

On the operations side: 

• Service level to stores increased from 93% to 97%; and 

• Days of inventory declined 2.5 days (18%). 




These positive results have led both Nabisco and Wegmans to 

decide to extend the timeline for this pilot and to expand its scope to 

include Milk-Bone pet snack products. 

In addition, commercially available collaboration software will be 

tested as potential technology solutions. 

Source: Condensed from Nabisco Inc. and Wegmans Food Markets, Roadmap to 

CPFR: The Case Studies, Voluntary Interindustry Commerce Standards Association 

14.8. SCM Systems 

A good SCM system is built on a framework that uses open technology 

and provides full support for industry standards, such as XML and 

CPFR. Such a system is flexible and interoperable with SCM systems 

of the trading partners. Apart from providing pre-configured functions, 

it also supports unique requirements of individual companies or sectors. 

One of the key requirements of an SCM system is to provide easy 

integration with a company's internal financial management, manufacturing, 

customer relationship management and legacy applications. 

The other functional specific features of an SCM system include: 

• Supply chain planning, demand planning, life cycle planning; 

• Supply chain event planning and management — for monitoring and 

responding to each stage of a supply chain and taking action in a 

real-time mode if activities are not going as earlier planned; 

• Real-time collaboration and communication with suppliers and 

distributors; 

• Materials management; 

• E-procurement; 

• Logistics; 

• Shared forecasts with suppliers; 

• Inventory planning, replenishment planning, manufacturing planning; 

• Full support for SCM practices, such as CPFR, VMI and collaborative 

order processing; 

• Order processing and purchasing;


• Resource utilization planning; 

• Collaborative design and fulfillment; 

• Transportation planning for inbound and outbound transportation; 

and 

• Product life cycle management to track product life cycle demand 

patterns and recommend future profiles, based on the product life 

cycle. 

SCM systems, typically, have a three-tier architecture, which includes 

the presentation tier (HTML, GUI-based front-end developed in 

programming languages such as Java, VC++), middle-tier comprising 

application servers with clustering solutions for load balancing and 

back-end comprising of database servers such as DB2, Oracle, Sybase, 

SQL Server. An SCM solution should be available for all the main 

operating systems — Windows 2000, Windows NT, Sun Solaris, HP- 

UX. 

The leading providers of SCM software include i2, PeopleSoft, SAP, 

Manugistics, Oracle and J.D. Edwards. 

Goal 

MITSUBISHI MOTOR SALES OF AMERICA — 

ENABLING DEALER COLLABORATION 

VIA THE INTERNET 

Strengthen Mitsubishi Motor Sales of America's (MMSA) new brand 

strategy and company revitalization efforts 

Strategy 

Ensure MMSA customers have the right car at the right place at the 

right time by implementing a Web-based order-to-delivery system 

Solution 

Manugistics NetWORKS Demand, NetWORKS Supply, and 

NetWORKS Collaborate, jointly implemented by Manugistics and 

Deloitte Consulting 



Results 


• Linked all of MMSA's 526 North American auto dealerships into a 

Manugistics-powered Internet-based collaboration system; 

• Slashed collective vehicle inventory in half; 

• Decreased age of vehicles on dealers' lots by more than 25%; 

• Cut vehicle lead times by more than 60%; and 

• Eliminated port stock, saving millions of dollars per year. 

The order-to-delivery solution, believed to be the first of its kind 

in the North American auto industry, allows MMSA to develop a 

profile of each dealership, based on factors such as dealer geography, 

customer buying patterns, product promotions, and sales seasonality. 

Dealers help refine these profiles, which can be shaped to cover 

key issues such as required materials and lead times, to help dealers 

forecast how many vehicles they should order to meet demand. 

Vehicle orders are then submitted by the dealers via the Web to 

MMSA. 

Since going live, the order-to-delivery solution has helped slash 

collective vehicle inventory (the number of cars MMSA and its 

dealers have on the ground at any given time) from a high of 80,000 

units to less than 40,000 units — all while experiencing sales increases 

of nearly 40 percent per month. The average age of vehicles on 

dealer lots has also decreased, from 166 days down to 38 days, 

resulting in fresher, higher quality products reaching customers. 

In addition, vehicle lead times have decreased by more than 60 

percent, reducing port and distribution center inventories. Port stock 

has fallen from 45,000 units at the start of the project to zero today, 

creating millions of dollars in savings for MMSA. 

MMSA's outstanding results illustrate the bottom-line success that 

is achievable using the power of intelligent Internet collaboration to 

create an eBusiness trading network of manufacturers, suppliers, and 

distributors that communicate and execute in real time. 

Source: Condensed from Mitsubishi Motor Sales of America: Enabling Dealer 

Collaboration via Internet, Manugistics Corp.



Supply chain management (SCM) is one of the most important 

applications enabled by B2B integration for various industries. SCM is 

a set of integrated business processes characterized by four underlying 

concepts: process optimization, combination of goods, services and 

information and extent of a supply chain. Companies that are positioning 

themselves as next generation enterprises (NGEs) are automating supply 

chain processes, which let trading partners exchange real-time information 

on the planning and execution of their respective supply chains. 

A B2Bi-enabled supply chain is demand driven which eliminates the 

need for companies to build inventories through forecasts that may or 

may not match the actual customer demand. It enables companies to 

consider all constraints, including material, capacity, logistics and 

financial, in real-time to best determine how to optimally plan, execute 

and deliver to meet customer demands, while ensuring profitable order 

fulfillment. 

SCM systems provide an end-to-end solution that integrates 

forecasting, planning and execution capabilities with complete supply 

chain wide visibility across the supply chain, which includes multiple 

distributed enterprises. A good SCM system provides seamless integration 

with external applications, such as a trading partner SCM system and 

internal applications, such as ERP, CRM and legacy systems. It also 

provides flexibility to add-on products on a need basis.

Chapter "] 5 

E-Marketplaces and Collaborative 

Networks 


B2B e-marketplaces align buyers, suppliers and commerce service 

providers into seamless trading communities. However, until e-marketplaces 

are integrated into companies' internal processes, real cost benefits 

of participating in them cannot be realized. 

In this chapter, you will come to know about the basics of B2B 

e-marketplaces and their integration with enterprise systems. You will 

also realize the importance of collaborative networks and how they will 

change the very nature of how companies do business with one another. 

438

15.1. What are E-Marketplaces? 

E-Marketplaces and Collaborative Networks 439 

B2B e-marketplaces, also known as hubs, are centers of commerce for 

the exchange of goods and services, driven by virtual electronic trading 

floors and an aggregation of buyers and sellers (see Figure 15.1). B2B 

e-marketplaces align buyers, suppliers and commerce service providers 

into seamless trading communities. They provide an environment for 

trading communities of common business interest where the buyers and 

sellers meet and trade with one another. By participating in e-marketplaces, 

companies reduce procurement and transaction costs and increase 

operational efficiencies for the exchange of goods and services. 

According to Forrester Research, 70% of the global 2500 companies 

participate in B2B e-marketplaces and more than 50% intend to 

participate in two to three of them. Despite the economic downturn, 

about 440 billion dollars' worth of B2B transactions are expected to 

flow through them, which would result in around 57 billion dollars of 

savings for the participating businesses in the year 2001 alone. The 

companies owning these marketplaces will generate revenue of 

approximately 23 billion dollars in the same period. 

The participation in these exchanges is beneficial to all small, 

medium and large companies. The main drivers for participation in B2B 

e-marketplaces include: 

• Distributed supply chain; 

• Push for market/operational process efficiencies, sales revenue and 

profitability; 

Sellers A Typical E-marketplace 

Sellers [Q| *.£ 

Collaboration 

Trading Events 

t-l* lO 

pf I 

Distributors fw" -,J j Spot cnnt- Purchase Pi irrhaco ~~| I 

Suppliers 

Manufacturers 

Jo 1 

Ivy 

Shared Workflow/ 

Process Matching 8* 

•'.PesTgrTarTd SburcThg] i 

lO Distributors 

^ I Excess Inventory M j ^ Retailers 

Figure 15.1. — A typical e-marketplace


• Complex purchasing information; 

• Reduction in new product rollout cycles; 

• Procurement process cost, which is a high percentage of the total 

cost; and 

• Purchasing, which is critical for companies. 

15.2. Basics of B2B E-Marketplaces 

In this section, we will discuss fundamentals of e-marketplaces. 

15.2.1. Pre e-marketplace era 

Before the advent of B2B e-marketplaces, companies used point-topoint 

integration (usually integrating back-end ERP systems) to conduct 

business securely with one another (see Figure 15.2). Buyers had 

to maintain static business relationships with a few suppliers. Such 

relationships were characterized by lack of competitive pricing. 

15.2.2. E-marketplace era 

In the B2B e-marketplaces era, companies do not have to bother about 

integrating their ERP system with trading partners' ERP systems. They 

can conduct business dynamically with any company in the world, 

Suppliers 

TllEI [••p ]••• TlIlP 

Buyers 

Figure 15.2. — Pre-exchange era


Suppliers 

1»»D TlllB (••D TlIlD 

E-marketplace 

A 4k. A. 4k 

Buyers 

Figure 15.3. — E-marketplaces era 

participating in that exchange (see Figure 15.3). B2B e-marketplaces 

are based on a 'many-to-many relationship'. 

15.2.3. Classification of e-marketplaces 

E-marketplaces can be classified as follows: 

Vertical vs. horizontal e-marketplaces 

Vertical — E-marketplaces that provide products and serve buyers and 

sellers of a specific industry, such as automotive or health care, are 

known as vertical exchanges. A few examples of vertical exchanges are 

e-Steel.com serving the steel industry, irail.com serving the railway 

industry and buckaroo.com serving the digital component market. 

Horizontal — E-marketplaces offering services and indirect goods that 

serve companies across all the industries are called horizontal exchanges. 

Indirect goods help the companies run their business, but are not 

necessarily part of a company's products. These marketplaces are like 

application service providers focusing on services that are common to 

all companies, such as transaction management, logistics, insurance, 

financing, credit and indirect goods, such as computers and stationery. 

Commerce One's Marketsite, Oracle exchange, VerticalNet, Ariba


Network and PurchasePro are examples of horizontal marketplaces. 

Most of these companies also provide buyer and seller packages that 

integrate their exchanges with a corporation's enterprise resource planning 

(ERP) system. 

Buyer vs. supplier controlled e-marketplaces 

Supplier centric or e-distribution sites — Supplier centric markets are 

developed, managed and run by major suppliers, such as Cisco and 

Marshall. In such markets, one supplier offers goods or services to 

several buyers (see Figure 15.4). It is the buyer's responsibility to do 

comparison-shopping. 

Buyer centric or e-procurement sites — Buyer centric markets are 

developed, managed and run by buyer(s) (see Figure 15.5). By installing 

Figure 15.4. — Supplier centric e-marketplace 

tP a 

Buyer 

^ 

Suppliers 

• • 

Figure 15.5. — Buyer centric e-marketplace


Buyers jr^ E-marketplace ^ Suppliers 

& Si 

Figure 15.6. — Neutral e-marketplace 

a buy-side portal, a company can link with all its suppliers that use 

catalogs to make their products available electronically and support all 

features of e-procurement. Purchases made through this system are 

directly linked back to the ERP system. A typical example of a buyer 

centric market is Covisint, which is a consortium hub by GM-Ford- 

Daimler-Chrysler. In these markets, smaller suppliers run the risk of 

high pricing pressures and competition from larger suppliers. Additionally, 

this model is too expensive for small-to-medium size buyers since they 

bear the responsibility of maintaining catalogs for each of their suppliers. 

Neutral — Neutral marketplaces (see Figure 15.6) are not controlled 

solely by either buyers or sellers. Everyone has an equal stake and 

opportunity to conduct business in neutral e-marketplaces. Buyers and 

sellers can even interchange their roles, with buyers becoming sellers 

and vice versa. They are best suited to markets with fragmented and 

distributed buyers and sellers. 

A few e-marketplaces may start off as either buyer or seller centric 

with the initial liquidity provided by the founding companies and can 

gradually evolve into neutral exchanges, for example, Tradespark — an 

exchange for energy traders. 

Open vs. private e-marketplaces 

Open — E-marketplaces that accept all companies meeting certain 

preliminary criteria that are common to all the participants are known 

as open e-marketplaces.


Private — E-marketplaces that restrict the participation of buyers and 

sellers, either because they are truly extranets or virtual private networks 

(VPNs) or industry-sponsored hubs for exclusive participants are known 

as private exchanges. 

Pass-through vs. brokered e-marketplaces 

Pass-through — E-marketplaces that are responsible for just the 

introduction of buyers and sellers are called pass-through exchanges. 

They do not offer any transaction processing services, leaving it to 

the individual parties involved. Such a model is suitable only for direct 

materials transactions where buyers and sellers do business based on trust. 

Brokered — E-marketplaces that facilitate the entire transaction, apart 

from providing a platform where buyers and sellers can meet, are called 

brokered exchanges. They are suitable for indirect material transactions 

(MRO — maintenance, repair and operating supplies like office 

stationery, etc.). 

15.2.4. Market makers 

Apart from providing typical e-marketplace services such as portal and 

mediator model-based exchanges, market makers actually provide 

liquidity and stability in the marketplace by buying from sellers and 

selling it to buyers. Market makers exert direct influence on demand 

and supply and thereby on the prices. This concept is very popular in 

the financial and utility industry. 

15.2.5. Dynamic trading through B2B e-marketplaces 

B2B e-marketplaces enable the formation of dynamic trading communities 

where a community of buyers and sellers can trade online. Dynamic 

trading occurs when market conditions, such as volatility, supply and 

demand and other external factors determine the price at which companies 

buy or sell goods and services. B2B dynamic trading occurs in the form 

of RFP/RFQ bidding, liquidating excess inventories, etc.


It has inherent advantages over fixed price trading because of its 

superior ability to: 

• Dynamically adjust the prices in situations with high uncertainty or in 

response to change in supply/demand (driving down prices to sell off 

end-of-life products and reduce the impact of inventory write offs); and 

• Allocate goods and services from those who can provide them most 

efficiently to those who value them the most. 

15.2.6. Governance of e-marketplaces 

Just as stock exchanges, such as the NSE and the NYSE, provide 

governance for trades transacted through them; in a similar way, 

e-marketplaces have to provide governance to ensure transaction 

reliability, enforceability, fairness and honesty in dealings among parties 

that trade on the exchange. E-marketplaces have to make sure that the 

participating companies do not misuse the system and uphold their 

responsibilities and obligations. E-marketplaces should set up a set of 

rules and procedures that define the dos and the don'ts of the operational 

standards and a standard of conduct for participants. 

The key features of a B2B e-marketplace governance mechanism are: 

• Standardization of the contracts that trade on the e-marketplace; 

• Agreements between the e-marketplace and its participants; and 

• Standing committees to assure enforcement and participant input. 

15.2.7. Benefits of B2B e-marketplaces 

The benefits of B2B e-marketplaces are: 

Common benefits to all participants 

Benefits enjoyed by all participants of an e-marketplace are: 

• Dynamic price determination due to real-time connections between a 

large population of buyers and sellers; 

• Optimization of resource utilization and improved scheduling and 

cycle times throughout supply chain;


• Secured transactions end-to-end; 

• Personalized services with full privacy protection; 

• Enhanced collaboration for design, development and fulfillment of 

new products; and 

• 24/7/365 access and support. 

Benefits to buyers 

E-marketplaces offer several benefits to buyers; for example, reducing 

order processing and e-procurement costs by as much as 60-70% per 

order. They are able to achieve such drastic reductions because of 

automating purchasing processes and workflow; obtaining greater 

transparency in product lines and suppliers; and aggregating purchases 

through the exchange. Participating buyers no longer have to wait 

endlessly for catalogs to arrive by mail and have manual intervention to 

place orders by phone or fax. 

By becoming a participant member of a B2B e-marketplace, buyers 

get the following services: 

• Access to multiple suppliers across the globe; 

• Real-time information pertaining to product offerings, product 

promotions, discontinued product closeouts and new product pricing; 

• Direct comparison of prices, terms and specifications; 

• Filtered and personalized industry-wide contents relevant to their 

interests; 

• Order fulfillment information that includes order status, shipping dates 

and back orders; 

• Contract management information that includes contract changes and 

expirations; and 

• Purchasing pattern-monitoring services that allow effective inventory 

maintenance. 

Benefits to sellers 

E-marketplaces have several benefits to offer sellers, including the 

lowering costs from process integration and collaborative supply chain. 

Some of the tangible benefits are:


• Access to new buyers in the same industry or other sectors across all 

geographic regions at minimal cost; 

• Easy announcement of a new product or a change in a product by 

publishing the information in just one place — the exchange; 

• Significant reduction of cost of retaining existing customers and 

acquiring new ones; 

• Automated order processing and transactions, which allows suppliers 

to respond in real-time to buyers' requests, resulting in better customer 

service; 

• Power to grow the market share by aggregating demand from multiple 

buyers; and 

• Improved efficiency and reduced inventory through automated supply 

chain cycle, which gives real-time access to demand information from 

all buyers. 

NTE EMPOWERING TRANSPORTATION MANAGEMENT 

Introduction 

The National Transportation Exchange (NTE) is an example of a 

successful vertical B2B trading exchange that has survived the B2B 

shakeout. The goals of the exchange are to offer greater connectivity 

among shippers and carriers for logistics optimization and to act as a 

singular transportation management and execution source for an 

industry that offers the best features of a dynamic market, as with 

perishable inventory. It generates revenue through the spread between 

the shipper and the carrier. 

NTE has a neutral marketplace for buyers and sellers to trade 

ground transportation at a market-driven price interactively (see 

Figure 15.7). It combines its online public marketplace with a private 

auction service that allows closed negotiations between trading partners. 

Who are the Participants? 

The exchange participants include shippers, consignees, third-party 

logistics providers, brokers, truckload carriers, freight forwarders and 

other intermediaries. 



NTE'S B2B/E-Commerce Trading Solution 

Supply Chain Management 

Ground Transportation Air Transportation 1 

Management K j 

Shippers 

Market-Based J Member-Specific! Value-Added 

Pricing J Requirements J Services 

Carriers 

Figure 15.7. — NTE's B2B trading exchange 

What are the Services Offered? 


NTE supports full execution around the logistics of transportation 

management and trade. Apart from providing just transaction services, 

such as doing a placement, generating notifications for the core carriers 

and placing the offer in the trading exchange, it also offers performance 

reporting and financial reconciliation services. 

Integration with Customer's Internal Systems 

Through its partnership with companies such as Manugistics, SAP 

and i2 Technologies, NTE is able to provide integration with 

customers' back-office internal systems. This enables customers to 

optimize freight movement with existing trade partners, with the 

option of using NTE's trading exchange for real-time pooling of 

less-than-truck-load orders. The exchange can then dynamically find 




a shipper with such matching parameters as location and size of load. 

This real-time collaboration among trading partners and exchange 

leads to better supply chain visibility, transaction abilities, visualization 

of the whole supply chain while inventory is in motion and cost and 

service efficiencies. 

Benefits to the Participants 

The benefits of shippers participating in NTE include guaranteed 

capacity, access to multiple carriers leading to optimum cost benefit, 

comprehensive reporting system on delivery loss, damages etc., 

compliance management and a single party to contact, a single check 

to write, a single point to access all transportation needs. They can 

also enter up to 150 business rules, such as freight type, shipment time, 

size, distance, routing, service levels and insurance requirement, which 

are the parameters considered during the matching of the orders. 

The benefits to the carriers include higher profit margins, full 

loads of transportation and access to multiple shippers. 

Source: Condensed from National Transportation Exchange: A Case Study, 

Strategis.gc.ca. 

15.2.8. Which e-marketplace to join? 

Since there are so many e-marketplaces with wide-ranging diversity in 

each industry, a company may face tough decisions about which exchange 

to join. The key factor that you should consider is the capability of the 

digital market to create a substantial value proposition directly affecting 

the bottom line. 

A few minimum criteria that a company must evaluate include: 

Goals of participating in an e-marketplace 

A company must detail the short-term and long-term goals of becoming 

a participant in an e-marketplace. Is it a big company? If so, can the 

company start its own buyer or supplier centric exchange rather than


participating in one? Is it a small company? If so, what kind of services 

and infrastructure support should it look for from e-marketplaces? 

These are the questions that companies have to raise and find the 

answers in-house. Once the goals are established, the hunt for an 

e-marketplace(s) can begin. 

Liquidity 

This is the single most critical factor that can make an e-marketplace a 

success or a failure. Without liquidity in an e-marketplace, sellers will 

not be able to find buyers and vice versa. There will be fewer transactions 

through the exchange, resulting in lower revenues and threatening its 

very survival. Thus, an e-marketplace should have a lot of participants 

in that vertical industry — big and small. 

Pursue your major customers 

As a supplier, a company cannot afford to lose its major customers. 

Companies should become members of B2B e-marketplaces that their 

major customers participate in. 

Focus 

It is essential to evaluate what the main focus group of any e-marketplace 

is. Is it small, medium or large size suppliers and buyers; or a combination 

of all three? It is equally essential to know the purpose of the e-marketplace 

— whether it is serving a horizontal or vertical community. 

Credit worthiness 

Since e-marketplaces enable buyers and sellers to transact business 

dynamically, they should either directly or through a third party accept 

the responsibility of certifying transactions. B2B transactions involve 

huge amounts, and credibility is an important deciding factor. Most of 

the e-marketplaces outsource the accountability of certifying buyers and 

suppliers and their credit worthiness to companies such as Identrus.

Enhanced services 


E-marketplaces should evolve from a transaction and supply chain 

aggregation based model to new models based on transactions, content, 

integrated e-procurement and collaborative supply chain. They should 

provide affordable, secure and single point of supply chain interaction 

and support integration with existing systems, such as ERP and order 

processing. 

Neutrality 

It is critical that e-marketplaces prevent any side playing a dominant 

role by dictating such matters as the technology and operational standard, 

since it should be neutral to all participants. Of course, if a company 

decides to participate in a buyer centric or a supplier centric exchange, 

the operating and technical standards would be dictated by them. 

Setup, participation and transaction fees 

Setup costs for participating in any e-marketplace should not be too 

steep. These costs may also be dependent on the volume of content that 

needs to be put online in the exchange. Several e-marketplaces do not 

charge any one-time participation or annual fees from buyers. They do, 

however, charge substantial fees from suppliers. So, as a supplier, a 

company should negotiate fees with companies running e-marketplaces. 

It may even create alliances with other suppliers and bargain for a 

group/volume discount. 

Some exchanges do not charge any participation fees even to suppliers. 

Suppliers pay fees (volume-based, percentage of total transaction or flat 

annual fees) only when they receive a confirmed order from buyers. 

Flexible, secured, scalable technology 

The technology supported by e-marketplaces should be flexible, so that 

it is interoperable with the internal systems of companies, and architecture 

should be flexible enough so that adding any off-the-shelf product (like 

adapters for internal systems) requires much less coding. Additionally,


the hardware and software on which e-marketplaces are built should be 

scalable and secured to support any number of transactions per day and 

have 24/7/365 availability. 

One of the main causes of the failure of many B2B e-marketplaces 

has been that available technology does not match with processes 

within companies. 

Content aggregation and distribution 

E-marketplaces should provide complete content management services, 

such as aggregation, formatting, cleansing, mapping, customization and 

distribution. They should incorporate supplier-neutral content as a 

foundation for content management and maintenance. No matter how 

good the trading engine of the exchange is, if buyers are not able to 

search and find products easily and suppliers are not able to publish their 

product contents to the e-marketplaces, there can be virtually no trading. 

Content management is one of the most difficult challenges involved, 

since the format of the data coming from multiple sources can be 

widely different. It has to be cleansed into standard formats like XML 

and parsed, so that it can be easily imported into the e-marketplace's 

platform and exchanged with trading partners. The contents should be 

dynamic (updated as and when the underlying data changes) with the 

facility of adding new products instantly. Distribution of customized 

content, such as contract pricing, volume discount and negotiation of 

terms between suppliers and buyers, should also be a part of this 

service. Most of the exchanges outsource this service to vendors such 

as Aspect Development and ec-Content. 

Support for EDI/XML-based documents 

E-marketplaces should be able to support all leading XML industry 

standards, EDI-based transactions and provide EDI-XML data conversion. 

Dynamic pricing 

The e-marketplace should create an environment where the supply 

meets the demand and the prices are determined dynamically through


services like auctions. Not only should the matching of trades be based 

on prices, but also factors such as logistics, warranty and quality. 

Interoperability with other e-marketplaces 

An e-marketplace should provide interoperability with other e-marketplaces. 

For example, CommerceOne.net, an open B2B e-marketplace, 

interoperates with all of the mega exchanges that are members of the 

Global Trading Web (an interconnected network of e-marketplaces). 

Negotiation 

Negotiation is one of the key factors for buyers to participate in an emarketplace. 

With this feature, buyers can pre-select qualified suppliers 

by filtering out those who do not meet basic criteria. They can then 

negotiate on a one-to-one basis with suppliers on various terms. All the 

key terms for negotiation should be electronically documented by the 

exchange for future reference. 

Training 

Lastly, e-marketplaces should provide appropriate and thorough training. 

Without proper training, internal users of companies may get overwhelmed 

with the application and its usage. 

15.2.9. B2B e-marketplaces services 

Some of the core services provided by an e-marketplace are (see 

Figure 15.8): 

Trading events 

• Auction — Auction services of e-marketplaces, leading to dynamic 

pricing, make them true exchanges. Auctions can be either seller or 

buyer centric. In the former, sellers list the item to sell and multiple 

buyers bid for this item. Through auctioning, suppliers can easily 

dispose of their excess inventories and generate revenue on inventory


Content 

User 

Profiles 

Catalogs 

News and 

Data 

Contacts 

Adapters 

Transformati on 

Translation 

Transactions 

Fulfillment 

Logistics 

Order 

Mgmt. 

Invoice/ 

PO,Other 

Requisition 

Source: Gartner Group 

Dynamic 

Trade 

Exchange 

Auction/ 

Reverse 

RFQ/ 

RFP 

Pricing 

Collaboration 

CRM 

Design &. 

Sourcing 

Demand 

Planning 

SCM 

Content Aggregation 

Shared Workflow/ 

Process Matching 

Catalog Aggregation 

Business 

Services 

Training 

Expert 

Advice 

Marketing 

Business 

Dev. 

Figure 15.8. — E-marketplace services 

Administration 

Personalization 

Permissions 

Tracki ng/ 

Audit 

Member 

Services 

Adapters 


Translation 

which otherwise would be written off. In buyer driven auctions, 

buyers specify the item to buy and multiple suppliers compete to get 

that order. Buyers can easily get discounted services or goods as 

downward pricing pressure is induced in such an auction. 

• Direct Selling — As the name indicates, direct selling allows direct 

dynamic trade between sellers and buyers of any e-marketplace. 

• RFQ/RFP — E-marketplaces should provide buyers the ability to 

submit RFQs and RFPs to all sellers. Through this service, buyers 

get multiple quotes for goods or service and sellers get sales leads. 

Full-service transactions 

• Logistics — As the volume of products transacted over B2B 

e-marketplaces increases, there will be a corresponding increase in 

the demand for management of the movement of these products. B2B 

e-marketplaces should directly or through external vendors provide


an infrastructure to execute transportation processes from dock-todock. 

• Order management — E-marketplaces should offer full order management 

services that can enable participant companies to effectively 

manage all aspects of purchases and sales order management. The order 

management system should automate the generation and distribution 

of documents, such as purchase orders (POs), PO changes, PO acknowledgments, 

invoices and goods receipts. It should tightly integrate all 

participants of a supply chain by enabling communication with third 

party financial institutions for electronic settlement, logistics provision 

and warehouse facilities. A system that provides end-to-end, realtime 

transparency of order flow throughout its lifecycle helps in 

drastically reducing the cash-to-cash cycle, minimizes the day's sales 

outstanding and makes supply chains more responsive. 

• Electronic Bill Presentation and Payment (EBPP) — According to 

the consulting firm Ovum, companies can save up to 70% in processing 

costs associated with distributing paper-based invoices by using EBPP. 

E-marketplaces should offer EBPP services, so that companies can 

streamline financial process management by selecting terms and 

schedules that fit their size and requirements. One of the best examples 

of EBPP service deployment is that of GE Global eXchange that has 

a billion transactions worth $1 trillion annually. 

• Secured messaging & data exchange — E-marketplaces should 

support secured messaging and data exchange services that accept 

and transmit data in various formats and communication protocols 

(such as ANSI XI2, UN/EDIFACT, EDI-INT, CXML, RosettaNet, 

HTTPS, SSL, FTP and other popular standards) that the participants 

use. 

Collaboration 

• Product collaboration — If an e-marketplace provides product 

collaboration services, the participating companies can collaborate in 

distributed product development to create innovative and profitable 

products (see Figure 15.9). This is usually a hosted subscription


Company C 

Figure 15.9. — E-marketplaces collaboration services 

service provided by an e-marketplace that needs heavy investment in 

staffing and infrastructure for networking, computing and security. 

The use of this subscription service would save a company a lot in 

extensive networking, computing, security and integration infrastructure 

required to support distributed product development. 

For instance, E2open — a leading secure collaboration network for 

the electronics industry, with participants such as Acer, Hitachi, IBM, 

LG Electronics, Lucent Technologies, Matsushita Electric (Panasonic), 

Nortel Networks, Seagate Technology, Solectron and Toshiba — provides 

very effective product collaboration services. 

• Supply Chain Management (SCM) — E-marketplaces should provide 

supply chain collaboration services (such as standard business process 

workflows in the areas of forecasting, planning and procurement), by 

offering a centralized hub, enabling supply chain collaborations on a 

shared many-to-many platform.


By linking the information systems of their trading partners, companies 

can immediately view changes in a wide variety of factors, including 

consumer demand and raw material supply. As a result, companies can 

respond to changing market conditions with rapid, intelligent decisions, 

reducing inventories significantly and maximizing manufacturing throughput. 

Companies will no longer compete enterprise-to-enterprise, but supply 

chain-to-supply chain 

15.3. How E-Marketplaces Fit into a Company's 

B2Bi Plans 

Until e-marketplaces are integrated into companies' internal processes, 

real cost benefits of participating in them cannot be realized. Integrating 

an e-marketplace involves complex interactions among back-office 

processes and systems, such as existing procurement, enterprise resource 

planning and supply chain applications. Some of the major integration 

issues that companies face are: 

15.3.1. Catalog publishing 

Each supplier has to publish the product contents for its buyers and 

exchanges. Each buyer and exchange may request its own format to 

accept the data. Suppliers run into grave problems when attempting to 

manage and maintain the product content for multiple channels. 

Solutions from companies like ec-Content solve this problem by 

accepting just a single feed of data from suppliers and generating output 

in multiple formats acceptable by major exchange vendors, such as Ariba, 

Commerce One, Oracle and i2. They also add value to the product information 

and pricing, making it easy for them to find, evaluate and buy. 

ec-Content's process works as follows (see Figure 15.10): 

Step 1 — Supplier provides the data feed to ec-Content. 

Step 2 — The Q-Centric process formats and enhances the supplier 

catalog products. 

Step 3 — ec-Content distributes the files to the supplier's customers 

and exchanges in whatever file format they require, for example text 

files, EDI, XML, MS Excel.


Supplier 

Data ^ 

E-marketplace 

Buyer 

The Q-Centrle 

Process Distributor 

Figure 15.10. — Q-Centric process — An example of catalog publishing 

15.3.2. Receiving and processing orders 

E-marketplaces have to be integrated with back-end business processes 

of receiving and processing orders to capture the advantages of supply 

chain integration, pricing and revenue optimization, electronic workflow 

and seamless transactional capabilities. This integration can be done 

either on a file-based batch interface or a real-time application programming 

interface (API) level. Several vendors, such as Commerce One, 

Ariba and RightWorks, provide both buyer-side and supplier-side 

solutions for fully automating the electronic flow of documents (such as 

purchase orders, purchase order acknowledgments, purchase order check 

and availability check). 

For instance, Commerce One provides XML Portal Connector (XPC) 

— a stand-alone, server-based application that resides at the supplier's 

site. This application provides an out-of-the-box, file exchange capability, 

using Java APIs for seamless integration between back-office systems 

(such as supplier's order management/ERP system) and Commerce 

One e-marketplaces. XPC installation includes the XML Commerce 

Connector, which provides secure, efficient and validated communication 

with an e-marketplace. 

The steps involved in a typical e-procurement cycle using XPC are 

(see Figure 15.11): 

Step 1 — The buyer (1) generates a requisition approved by Enterprise 

buyer (2) and stored in the Enterprise buyer database (3). Enterprise 

buyer generates an approved purchase order in the form of an XML file

Buyers 

© BE': via the Internet 

by HTTP/S and 

Enterprise Buyer the MarketSite [I 

»•§•. o 

Enterprise Buyer 

Database/ERP Integration 

Messaging 

Layer 

e 

m 


Market- 

Site 

e 

MarketSite 

Data System 

Web Server 

running 

Suppy Order 

via the Internet by 

HTTP/S and the 

MarketSite 

Messaging Layer 

or a Standards 

Based Gateway 

o 

Supplier 

o o 

Supplier XPC, „ S " pp, i? r 

ThiKrf „=.*./ Back-office 

Third-party em*.. 

Product, 

or Gateway Receiver 

(e.g. OBI server) 

Figure 15.11. — Commerce One's XPC solution for integration 

System 

(xCBL) representing this requisition. The file is securely sent over the 

Internet to MarketSite (4) — Commerce One's e-marketplace. 

Step 2 — MarketSite sends the newly arrived POs via HTTPS and 

the MarketSite messaging layer, or via a standards-based gateway, 

to the supplier's XPC or a gateway receiver (8). The receiver submits 

the PO to the supplier's back office system (9), gets a PO response, 

builds a response document, then returns it to MarketSite (4), which 

optionally reformats the results (e.g., transforming OBI 855s to xCBL 

OrderResponse documents) and sends them to Enterprise buyer (2). 

Enterprise buyer stores the results for display to the end user (3). 

15.3.3. Data transformation 

In each industry there has been a proliferation of XML standards, 

which are not compatible with each other. Thus, employing a solution 

that integrates a legacy system with one e-marketplace may fail drastically 

in linking to another e-marketplace. For example, Ariba uses cXML 

while Commerce One uses ebXML. These flavors of XML are not 

compatible with each other. 

Companies have to deploy a data translation server, which may be a 

part of a B2B application server that accepts any file format from 

buyers and sellers such as flat files, EDI, XML (all leading standards) 

and transports them to their clients. Data transformation vendors include


CardoNet, OnDisplay, Cohera, webMethods, Cyclone Commerce and 

StreamServe. 

For instance, StreamServe Business Communication Platform 

represents a flexible communication layer that allows automated 

communication processes to be defined in a unified and structured 

manner. StreamServe processes multiple incoming documents and 

prepares them for output in a structured data stream to the receiver, 

based on pre-determined communication rules. 

15.3.4. Integrating credit, financing and collection 

system with ERP 

Dynamic trade with unknown parties in B2B e-marketplaces can be 

risky at times. In order for a company to safeguard itself from malicious 

trades, it needs to integrate credit, financing and collection components 

with ERP systems, which enables automated credit reviews of new 

customers, identify and pre-qualify new customers, streamline collection 

processes and automate enterprise-wide receivables management. 

The credit system would accept an application from a customer, 

retrieve information about the credit history from a credit bureau such 

as EDGAR (this information may come in different formats), clean the 

data to a single uniform format, make a decision on the credit limit — 

based on the credit rules that a company may have fed into the system 

— and send out a response to the customer. This whole process has to 

be fully automated and completed at Internet speed. 

15.4. Emergence of B2B Collaborative Networks 

There are several prominent reasons that have led to the failure of most 

of the e-marketplaces. From an integration and services point of view, 

the important ones are: 

15.4.1. Just another point of connection 

B2B e-marketplaces act like middlemen, bringing buyers and sellers 

together. However, there are multiple exchanges sprouting in each

Company A 

Application 

Application 

t-marketplace X 


.^plication 

Company B 

/•^plication 

Application 

Application 

Figure 15.12. — The B2B traffic jam 

Company C 

Application 

Application 

C-marketplace ¥ 

vertical industry, each supporting different technology and different data 

formats. Each company eventually plans to participate in multiple 

exchanges. In order to participate in each individual exchange, companies 

have to establish a connection. Establishing, managing and maintaining 

a multiple point-to-point connection (see Figure 15.12) between a 

company, trading partners and e-marketplaces is extremely difficult and 

expensive. 

The more e-marketplaces that a company participates in, the greater 

the transaction data formats that it has to support (see Figure 15.13). 

This may make the whole scheme error prone as it takes only one slight 

error in format to cause transactions to fail.


I I f •"»•' t I I 

tut XEDI RosettaNet Plat Hie cXML ebXML 

Supplier Supplier Supplier Reseller E-marketplace E-marketplace 

Figure 15.13. — Different data formats for e-marketplaces 

Thus, there are severe shortcomings of point-to-point connection 

mechanism (with e-marketplaces being a point of connection themselves), 

such as: 

• Disparate technologies and platforms used by buyers, sellers and 

marketplaces, leading to integration headaches; 

• Insufficient leverage of existing technologies like EDI; and 

• Budding B2B standards that are far from maturity. 

All these have created the need for a single point of connection which 

all of the trading partners, intermediaries and e-marketplaces can use. 

15.4.2. Lack of support for collaborative commerce 

Collaborative e-commerce, also know as c-commerce, is enabled through 

a collaborative framework that integrates cross-organization business 

process, customer relationships and knowledge. C-commerce is the next 

generation of e-commerce, that brings about an evolution of the traditional 

supply chain process. 

E-marketplaces primarily focus on constructing a virtual community 

of trading partners to buy or sell goods and services. But the scope of 

collaborative commerce is far beyond just trading. 

15.4.3. B2B collaborative networks 

B2B collaborative networks enable formation of collaborative trading 

communities and any-to-any connectivity by linking together buyers,

Company A 

fe3 

Application 

Application 

Application 


Application 

B2B Collaborative 

Network 

Application 

E-marketplace X 

Figure 15.14. 

Company B 

Application 

Application 

Application 

Company C 

Application 

Application 

E-marketplace Y 

B2B collaborative network 

suppliers and e-marketplaces (see Figure 15.14). They provide open 

interfaces to tie together all the participants' applications into an 

integrated network, thereby creating a single, collaborative and responsive 

B2B e-commerce solution. By participating in such a network, a company 

transacts business with all its trading partners using a single connection, 

a single format (see Figure 15.15) and only a single method of security. 

According to The C-Commerce Framework report by the Gartner 

Group, companies that employ a collaborative commerce framework 

can expect a 40% gain in profitability by 2003. 

Some of the services of the networks include (see Figure 15.16): 

• Integration — Provides full integration with the internal systems of 

the companies and thereby leverages existing infrastructure, such as


Supplier 

Figure 15.15 

Supplier Relationship 

Management 

_£3LCb— 

Buyer 

t 

Buyer's Preferred Format 

. I- • 

B2B 

Reseller E-marketplace E-marketplace 

Single data format for B2B collaborative networks 

Collaboration Services 

such as New 

Product Development 

Supply Chain 

Management 

Trading and 

Commerce 

Any-to-Any 

Connectivity 

Services of 



Networks 

Value-added Services 

such as Logistics, 

Freight and Settlement 


Transaction 

Management 

Content 

Management 


Relationship Management 

Figure 15.16. — Services of B2B collaborative networks


EDI. Supports all the leading Internet technologies (PKI, SSL, Digital 

Certificates, LDAP, XML and different industry standards); 

• Content — A robust, searchable, interoperable content infrastructure 

that requires suppliers to publish catalog content once in a single 

format; 

• Collaboration — Includes design collaboration, supply collaboration, 

supply chain planning and inventory visibility features; 

• Connectivity — Buyers can link their Supplier Relationship 

Management (SRM) systems, ERP and e-procurement systems; and 

suppliers can link their Order Management, ERP and CRM systems 

with the network through private networks (VANs) or the Internet; and 

• Commerce — Includes RFQ and auctions, order management, financial 

settlement and logistics. 

For example, any-to-any connectivity provided by i2's Tradematrix 

Open Network Commerce (see Figure 15.17) helps enterprises, 

marketplaces and service providers interact seamlessly. 

I 

Buyers 

^gTradeMatrlx Open Commerce Network rf^. 

Private 

Sellers 

V 

Q I Enterprise 1 

I J 

Figure 15.17. — i2's TradeMatrix Open Commerce Network


Ariba Commerce Services Network (Ariba CSN) and Commerce 

One MarketSite are other examples of such networks. They provide 

solutions from basic interoperability and connectivity to advanced 

capabilities for specialized commerce processes. 


E-marketplaces are one of the best B2Bi-enabled applications. The 

benefits of an e-marketplace for both buyers and sellers are considerable, 

depending upon the transaction mechanisms and services offered by the 

marketplace and the industry served by it. Participants have the ability 

to negotiate better pricing, reduce transaction costs and reach a broader 

range of customers or suppliers. 

Companies should carefully consider their short-term and long-term 

procurement and supply chain strategies and minutely evaluate the 

services and features of an e-marketplace before deciding to invest in it. 

The need for any-to-any connectivity has given rise to B2B 

collaborative networks, which allow multiple trading partners and 

e-marketplaces to replace dozens, sometimes hundreds, of point-to-point 

connections with a single connection to the network.

Part IV 

B2Bi-Enabled Applications 

467


Chapter "| Q 

B2B to P2P Evolution 


Peer-to-peer (P2P) computing represents the next revolution in the B2B 

domain, as it will dramatically alter the way businesses communicate, 

collaborate and exchange data over the Internet. 

In this chapter, which is also the concluding chapter of the book, we 

will imagine the future of B2B applications as they are being shaped in 

the form of P2P-based architectures. Through examples, we will show 

the benefits of P2P applications in B2B integration. 

469


16.1. Why Peer-to-Peer? 

Throughout this book, the emphasis has been on efficient use of the 

three prime resources of the Internet — information, bandwidth and 

computing resources — for all current and future B2B applications. 

However, with the current client-server type architectures of B2B 

applications, which have relatively fewer servers and many clients, 

these resources are grossly underutilized. 

In this final chapter of the book, we will discuss a new revolution, 

peer-to-peer (P2P) computing that could change radically the business 

models, applications and enterprise technology management approaches. 

Peer-to-peer computing based architecture allows for decentralized 

application design, moving from centralized server models to a distributed 

model where each peer, independent of software and hardware platforms, 

can benefit and profit from being connected to millions of other peers. 

In such architectures, clients and servers have a lateral relationship, 

rather than the traditional vertical relationship, giving the whole peer 

group tremendous processing power, storage space and network 

bandwidth. This revolutionary change allows every networked machine 

to connect to another machine, fully leveraging the previously unused 

resources and changing the B2B landscape. 

16.1.1. Let your imagination run wild 

Imagine a world in which billions and billions of electronic devices, all 

part of peer networks, seamlessly exchange messages and run applications 

among themselves. Imagine a world in which there is no need to load 

any software on computers, PDAs, cell phones. Imagine freedom from 

permanent IP addresses, domain names and registration with domain 

name servers. Imagine fully utilizing the worldwide computing resources 

of approximately 300 million PCs with average processing power of 

300 MHz and 3 GB drives on average. Imagine access to all the net 

connected PCs with 90 billion MHz of processing power and 300 

thousand terabytes of storage. 

P2P can make this fantasy come true. This is surely much bigger 

than the Internet revolution.

B2B to P2P Evolution 471 

Many major companies, including Intel (Peer-to-peer Working Group), 

Sun Microsystems (Juxtapose) and Microsoft (.Net) are inputting 

extensive resources to build a future based on this vision. 

16.1.2. What is P2P? 

Peer-to-peer computing is the direct sharing of computer resources and 

services between systems, without the use of a centralized server. P2Pbased 

architecture eliminates the need for setting up and managing a 

centralized infrastructure. 

Put simply, P2P clients talk to one another directly, without going 

through a central server. The client can range from a large multiprocessor 

server to a small desktop computer to a handheld device. 

It involves file sharing, exchange of processing cycles, cache storage, 

messaging, Web services and distributed services. This architecture 

harnesses the typically unused, high desktop computing power of 

each individual computer in the entire enterprise. It is the collective 

power of so many client nodes, also acting as servers that redefines 

the effective utilization of resources. The most popular example of 

a P2P-based application is Napster, although it is not business-tobusiness. 

16.1.3. What is a peer group? 

A peer group can be defined as a collection of peers that agree to a 

common set of rules to generate, publish and exchange information. It 

is up to the group members to decide the governance rules like 

membership policy from public (open to all) to private (highly secured 

— open only by invitation) group. 

16.1.4. Features of a P2P application 

The most basic requirements of any P2P application are peer discovery 

and peer communication. A P2P application has the following typical 

features:


Ability to discover other peers 

A P2P application should be able to locate other peers in the network. 

Since P2P networks cannot operate in an environment of stable 

connectivity and fixed IP addresses, the nodes (each device in the 

network is known as a node) have to operate outside Domain Name 

Service (DNS — converts names to IP addresses) system. 

So, how are the peers able to locate each other? Well, this can be 

achieved in a pure P2P-based architecture (see Figure 16.1) by network 

broadcasting and in a P2P-based architecture with a central server (see 

Figure 16.2), which is used to maintain a list of all the current 

Peer 

Figure 16.1. — Pure P2P-based architecture 

Figure 16.2. — P2P-based architecture using a central server


participating applications and distribute this information to all the 

requesting applications. 

Ability to communicate with peers 

After an application is able to locate the peers, it should be able to 

communicate with them using messages. The communication can be a 

request for content, which can be originated by the user or by the 

application itself. 

Ability to share information with other peers 

Once the communication is established with other peers, the application 

should be able to receive and provide information such as content and 

data to them. 

16.2. Leading P2P Protocols 

Some of the leading P2P protocols are as under: 

16.2.1. Jabber 

Jabber is an instant messaging and presence notification, open source 

XML-based protocol. Since it is platform neutral, Jabber is interoperable 

with messaging across both wireless and browser based messaging 

services. 

The real-time messages are exchanged as XML streams. Jabber's 

open XML protocol contains three top level XML elements, which in 

turn contain data through attributes and namespaces. 

1. — contains messages that are exchanged among Jabber 

users; 

2. — provides availability information about Jabber entities; 

and 

3. (info/query) — structures a rudimentary conversation between 

any two entities in Jabber and allows them to pass XML-formatted 

queries and responses back and forth.


16.2.2. Juxtapose — JXTA 

JXTA derives its name from the fact that peer-to-peer is juxtaposing to 

client/server or Web-based computing. 

JXTA is an open network platform for P2P computing. It provides a 

framework and a set of protocols that standardize the way in which 

peers discover, advertise network resources, communicate and cooperate 

with each other to form secure peer groups. All the functions supported 

by JXTA are performed by publishing and exchanging XML messages 

among participating peers. 

JXTA is independent of programming language. Heterogeneous digital 

devices, such as PCs, servers and PDAs, and appliances with completely 

different software stacks can interoperate with JXTA protocols. Moreover, 

it is independent of transport protocols, such as TCP/IP and HTTP, and 

can be implemented on top of them. 

JXTA architecture 

As depicted in the JXTA architecture figure (see Figure 16.3), JXTA is 

essentially divided into three layers: 

JXTA 

Application i 

JXTA Community Application 

Sun j: TA 

Application 

3XTA I f SUN indexing 

&.„,i— i JXTA Community Services I JKTA 'Searching 1 ' , , 

SerViC ** I I Services *File Sharing 3 Commends . 

JXTA 

Core 

Pea Gioups Peer Pipes Peei Monitonng 

Secunt,' 

Any tea* on ih« I I Web 

Figure 16.3. — JXTA architecture


1. Core Platform — This layer enables interoperability among all 

P2P devices. It encapsulates services that are mandatory for P2P 

networking, such as peers, peer groups and peer monitoring. 

2. Services — This layer encapsulates the non-mandatory but desired 

network services, such as searching, indexing and file sharing. 

3. Applications — This layer includes P2P applications, such as instant 

messaging, content management and delivery. 

JXTA protocols, messages and advertisements 

JXTA protocols are the common threads among JXTA peers. Each 

protocol, as defined by JXTA, involves exchange of one or more 

messages (based on a pre-defined format) and advertisements among 

the peers. 

A JXTA message consists of an envelope, which defines fields such 

as destination address and source address and a stack, which contains 

the body of the message and its relevant information (see Figure 16.4). 

An advertisement is an XML-structured document and, therefore, 

platform independent, that names, describes and publishes the existence 

of a resource, such as a peer, a peer group, a pipe, or a service. 

Envelope 

Stack of 

Messages 

9 Ixta:// I Envelope Version 

i C«1MIRWeMmBttMaiiaiIIHBIHIHHîMH«; 

Figure 16.4. — JXTA message definition


Example of an advertisement — Peer advertisement 

As the name itself indicates, a peer advertisement describes peer 

information. It is represented as an XML document that contains peer 

information, such as name, peer id, services and properties. 

An example of a peer advertisement: 

 

 

Name of the peer 

Search Keywords for this Peer 

Peer Id 

Peer Properties 

Service Advertisement 

Service Advertisement 

Endpoint Advertisement 

 

The protocols implemented in JXTA are: 

1. Peer Discovery Protocol — It enables a peer to find advertisements 

on other peers and can be used to find any of the peers, peer groups, 

or advertisements. 

2. Peer Resolver Protocol — It enables a peer to send and receive 

generic queries to search for peers, peer groups, pipes and other 

information. 

3. Peer Information Protocol — It allows a peer to learn about other 

peers' capabilities and status. 

4. Peer Membership Protocol — It allows a peer to obtain group 

membership requirements, to apply for membership and receive 

membership, to update an existing membership or application 

credential, and finally, to cancel a membership or an application 

credential. 

5. Pipe Binding Protocol — It allows a peer to bind a pipe advertisement 

to a pipe endpoint, thus indicating where messages actually go over 

the pipe.

B2B to P2P Evolution All 

6. Peer Endpoint Protocol — It allows a peer to ask a peer router for 

available routes for sending a message to a destination peer. 

16.3. Examples of P2P Applications 

Below is a brief description of some of the P2P-based applications that 

are useful in B2B e-commerce: 

16.3.1. NextPage — NXT 3 

NextPage's NXT 3 e-Content Network joins distributed content 

management systems, corporate portals, groupware tools, databases and 

Web servers in a peer-to-peer content network. In this environment, 

each content site contributes all or part of its resources to the Content 

Network, without having to move anything to a central location. 

The NXT 3 platform (see Figure 16.5) includes: 

• Integrated search engine, so that users can search and retrieve content 

located anywhere across a distributed network; 

• Security component for distributed environment, which manages 

e-business security policies using Access Control Modules (ACMs), 

SSL and RSA data encryption; and 

NXT3 

Search 

Enqkie 

Distributed Content 

Network Platforms 

NXT3 

Content 

Syndicatoi 

Loral Content 

Management .Solution 

Nxrs 

Content 

Adapter* 

i 

NXT 3 

Senility 

Services 

NXT3 

Content 

Server 

Other Information 

Sources 

Figure 16.5. — The NXT 3 e-Content platform 

(•iniiimvare


• Content adapters to enable direct and P2P integration like adapters 

for ODBC compliant databases such as SQL Server, Oracle and 

Sybase. 

16.3.2. FirstPeer — Professional servant 

FirstPeer offers an open platform, person-to-person application 

development tool, called the Professional Servant. The Professional 

Servant manages the interaction among applications and devices on a 

direct P2P basis. It extends and builds upon the basics of traditional 

DNS, HTTP, XML, XML-RPC and Jabber instant messaging, to address 

the opportunities in P2P marketplaces and commerce. 

16.3.3. Groove networks — Groove 1.0 

Groove is a peer computing platform designed to host a broad range of 

peer-to-peer applications and business solutions for collaboration — 

particularly security and synchronization. The solution enables instant 

messaging, live voice, file sharing, free-form drawing and other ways of 

working together. 

16.3.4. Gnuetella 

Gnuetella is a distributed P2P file sharing system, which does not 

require a centralized server. Gnutella allows a user running a Gnutella 

client to search for and download files from other Gnutella users. 

Companies can use it to serve files into the intranet from any device on 

the network. 

16.3.5. Applied MetaComputing — Legion 

Applied Meta provides a comprehensive middleware that has a complete 

set of capabilities for developing robust P2P and distributed computing 

solutions. Their technology provides a scaleable and secure framework 

that allows enterprises to effectively manage distributed systems, which 

include network servers, desktops, clusters and handheld devices across


geographically dispersed locations. In crux, it enables one to build a 

system that can encompass multiple organizations, architectures, operating 

systems and physical locations. 

16.4. Benefits of P2P-Based Applications in 


All enterprises — small, medium and large — can effectively use P2P 

applications for several B2B related tasks. For instance, buyers can use 

P2P networks to search and find suppliers, products, etc.; suppliers can 

easily distribute their catalog information, complete a B2B transaction 

with their trading partners and use P2P for effective customer relationship 

management. Cycle sharing, collaboration, knowledge management and 

secondary e-commerce are some of the distinct benefits of P2P 

Benefits and applications of P2P in B2B include: 

16.4.1. Collaboration 

P2P applications enable internal and external product design and 

development groups to communicate, share data and work transparently, 

over the Internet or behind the firewall. Clients always have access to 

fresh data, which can be stored locally, thereby reducing the network 

traffic. P2P-based collaborative environments are very flexible as there 

is no need of a central server, any device can act as a peer, and they can 

be disassembled as soon as the group goal is achieved. 

For instance, Ford will use peer-to-peer technology as a way to 

produce more fuel-efficient cars. It plans to connect design teams 

located in multiple sites that are using different operating systems and 

applications, which will save them between $5 million to $15 million 

per vehicle design program. 

16.4.2. Enhanced performance 

B2B integration requires real-time exchange of data in the form of 

messages among the participating companies. P2P-based applications 

distribute the resources and computation over the network, thereby 

reducing the distances (less latency) for messages and data to travel. In


addition, with the use of a network of computers, businesses can 

logically distribute large computational jobs across several computers 

and the results can be shared directly among participating peers. 

Through the use of computing resources untapped in the past, which 

reduce the load on main servers and allow them to perform specialized 

services, organizations can dramatically lower the processing costs and 

speed up the process completion times. 

DATASYNAPSE SPREADING THE COMPUTING POWER 

DataSynapse helps customers harness idle and underused computing 

power in their network. They provide a product called WebProc*, 

which is a peer-to-peer platform for distributing compute-intensive 

application processes to idle and underutilized resources. The solution 

does not discriminate, based on whether the resources are in rackmounted 

servers or high-performance desktop PCs. As long as they're 

on the enterprise network, WebProc will use them to perform 

demanding processing tasks. 

The solution integrates easily with the corporation's existing 

network environment. Employees never notice that WebProc is 

working, because it only takes control of a desktop PC when that 

PC is idle. Should a worker return to his desk during a computation, 

WebProc immediately interrupts the processing task and reroutes it to 

another idle system. 

The results of the DataSynapse WebProc solution are impressive. 

In one installation at a retail banking corporation, where crunching 

complex derivatives contracts requires a lot of power, performance 

improved by a factor of 80. Baseline time to process 200 trades on an 

existing server was 44 minutes. By distributing those computations 

across 100 Intel®-based PCs, the job finished in 33 seconds. 

Completing such jobs faster is invaluable to a financial services 

company. It can boost the productivity of traders, allow a bank to 

react more swiftly to abrupt economic changes and generally increase 

the number of trades a company can conduct. What's more, scaling 


such a system 

incredibly easy. 

to handle more and more complex 



calculations is 

Source: Condensed from Peer-to-Peer — Spreading the computing 

power, Intel 

16.4.3. Intelligent agents 

Peer-to-peer computing allows peer networks to work together 

dynamically using intelligent software agents, which reside on the peer 

nodes. These agents can find and communicate with each other. They 

can be used to prioritize tasks on a network, change traffic flow, search 

for files locally or determine anomalous behavior, such as a virus, and 

stop it before it affects the network. 

For instance, Sandia Labs' virus protection agents communicate 

suspicious behavior to other peers on the network and get them all to 

take the necessary action to stop the threat. 

Another example is that of Consilient, which allows businesses 

to create intelligent agents that carry out business processes (see 

Figure 16.6). The intelligent agents advance a business process by 

moving control and data directly between peer clients via personalized 

user interfaces. This technology can be used to automate business 

processes, such as procurement or other collaborative tasks. 

Consilient technology links automated and manual tasks to help 

companies and individuals take control of diverse and dynamic processes 

that span multiple systems, people and organizations. It allows customized 

information and tasks to be aggregated and distributed to the appropriate 

individuals within a particular business process. The results are greater 

collaboration across extended enterprises and processes that are more 

efficient and innovative. 

16.4.4. P2P marketplaces 

P2P marketplaces eliminate the middleman — a centralized B2B 

e-marketplace — and let buyers and sellers trade directly. They offer


Email Pile Web Page 

Detached & Static Content 

Task Agents 

Clai rfy 

Figure 16.6. — Consilient's peer-to-peer framework 

Ai iba 

Application Content 

some compelling advantages over the B2B exchange based model. First, 

and most obvious, they permit companies to avoid the fees charged by 

e-marketplaces. Second, they reduce the complexity and expense of 

networking. It is much easier for a company to integrate its internal 

information systems with a single P2P program or 'peering portal', than 

with a bunch of different exchanges. Finally, while membership among 

exchanges is limited, often determined along industry lines, P2P 

marketplaces have no bounds. 

For example, GnuMarkets is the first dynamic distributed marketplace 

available in the peer-to-peer industry, where buyers and sellers can buy, 

sell and trade items in a secure environment. GnuMarkets uses the 

bandwidth, data storage and CPU of each participant, which eliminates 

the need for central servers and lowers costs. 

The services offered by a P2P exchange are manifold. The important 

ones are to: 

1. Provide a directory service where the track/record of IP addresses of 

participants can be maintained;


2. Trace new buyers and sellers; 

3. Keep aggregates of all products offered for purchase and catalog 

sale; 

4. Maintain folders detailing products vis-a-vis prices for comparison; 

5. Provide workflow function to automate deal closing procedures 

consequent to finalization of negotiations; and 

6. Store the terms of deals in archives after their consummation. 

16.4.5. Information discovery using search engines 

Search engines are among the most widely used applications based 

on P2P technology. According to Forrester research, approximately 2 C 

10 E 18 bytes of data is produced in the world every year, out of which 

only 3 C 10 E 12 bytes of data is published (i.e. only a single byte out 

of every megabyte of information generated is physically published). 

Even the most advanced search engines such as Yahoo, Altavista and 

Google search only a small fraction of the total information that is 

published. Therefore, current search engines cannot provide up-to-date 

and precise searches of electronic data like catalogs and industry news 

that is increasing at an exponential rate daily. 

Search engines are relevant in several aspects of B2B e-commerce. 

For example, buyers can search across suppliers' computers and see 

real-time prices. InfraSearch is a typical example of a P2P-based search 

engine. Its technology makes it possible for content companies to return 

more useful results when searched. For example, database-driven sites 

can retrieve formatted results from within their databases, which is not 

possible with typical search engines. 

16.4.6. Eliminate the need for cataloging in 

multiple formats 

P2P helps in resolving suppliers' problems of publishing, distributing 

and maintaining catalog information. It frees them from the hassle of 

distributing the catalogs in multiple formats, as expected by B2B emarketplaces 

and buyers. With P2P-based applications, suppliers have 

full control of data format.


16.5. But the Road is Winding 

P2P technology is indeed alluring. But the road to designing, developing 

and executing P2P-based applications is not a straight one. There are 

several major challenges that may hamper its early adoption, especially 

in B2B applications. 

Some of the potential problems with P2P-based architectures in the 

light of B2Bi follow: 

16.5.1. Network bandwidth 

A critical factor of the success of peer-to-peer technology is the 

bandwidth available. If companies use P2P-based applications for B2B 

integration, it may severely slow down their network connections and 

hamper the core business activities. By definition, P2P applications 

eliminate central servers and create a loose, dynamic network of peers. 

For any content retrieval operation, such as a search for a specific item 

in a catalog, all the peers in the network are searched, using a lot of 

network bandwidth. As this network size increases and becomes more 

distributed, it may be affected by poor and slow connections. Further, 

as the number of peers searching for content or communicating in the 

network increases, the resulting traffic can potentially block the whole 

network bandwidth. 

For instance, the traffic generated by Gnutella, an open, decentralized, 

peer-to-peer search system for files, is enormous. A Gnutella search is 

broadcast across a network that changes from moment to moment, 

going from one individual computer to four others, from those to sixteen 

others and so on. The search results are returned along the same 

pathway they originally traveled. 


The most important feature of the P2P-based application — decentralized, 

distributed architecture — is also its weakest link. P2P applications 

pose major security threats to companies, as by definition the peer 

network involves distributing data and computing resources over several 

peers. B2B applications require communication with external parties,


making it easy to break even robust enterprise security features by 

passing a bad remote command execution or files containing viruses. 

Moreover, these applications require access through the corporate 

firewall, which may potentially open up a major security hole in the 

firewall that can be exploited maliciously both by internal and external 

users. 

16.5.3. Complex architectures and 

difficult maintenance 

The architecture of P2P-based applications for B2B integration is 

extremely complex as it involves security issues and the use of distributed 

resources in an optimal way, making decentralized and independent 

systems work as one. Maintenance of such applications is much more 

difficult, since it is extremely tough to identify, replicate and fix 

application or network related problems. 


P2P, a next-generation computing architecture, is still evolving. P2P 

networks are the future — networks based on high speed, with any 

electronic device attached to them, that do not need any centralized 

servers and in which each device acts as a client and a server. 

P2P computing represents the next revolution in the B2B sphere, as 

it will dramatically alter the way businesses communicate, collaborate 

and exchange data over the Internet. However, P2P is still in its infancy 

and much work still needs to be done, as well as many industry 

standards and specifications still need to be established.


Acronyms 

1G First Generation. 

2G Second Generation. 

3G Third Generation. 

3GL Third-Generation Language. 

4GL Fourth-Generation Language. 

AMPS Advanced Mobile Phone System. 

ANSI American National Standards Institute. 

API Application Programming Interface. 

APPC Advanced Program-to-Program Communication. 

ASCII American Standard Code for Information Interchange. 

ASP Application Service Provider. 

AUC Authentication Center. 

B2B Business-To-Business. 

B2Bi Business-To-Business Integration. 

B2C Business-To-Consumer. 

B2E Business-To-Employee. 

B2P Business-To-Peer. 

BUOW Business Unit Of Work. 

C/S Client/Server. 

CDMA Code Division Multiple Access. 

CDPD Cellular Data Packet Data. 

CDR Clinical Data Repository. 

CE Compact Edition. 

cHTML Compact Hypertext Markup Language. 

CIF Catalog Interchange Format. 

CMMS Computerized Maintenance Management System. 

COM Component Object Model. 

487


CORBA 

CPG 

CPI-C 

CRM 

CSS 

cXML 

DBMS 

DC 

DCOM 

DML 

DSOM 

EAI 

EAM 

EBCDIC 

ECMA 

E-commerce 

EDA/SQL 

EDGE 

EDI 

EDIFACT 

EFT 

EIP 

EPOC 

ERP 

F&B 

FM 

GCOS 

GPRS 

GSM 

GUI 

HCO 

HDML 

HL7 

HRMS 

HTML 

The Object Management Group's Common Object Request 

Broker Architecture. 

Consumer Packaged Goods. 

Common Programming Interface for Communications. 

Customer Relationship Management. 

Customer Service and Support. 

Commerce Extensible Markup Language. 

Database Management System. 

Distribution Center. 

Microsoft's Distributed Component Object Model. 

Data Manipulation Language. 

IBM's Distributed System Object Model. 

Enterprise Application Integration. 

Enterprise Asset Management. 

Extended Binary-Coded Decimal Interchange Code. 

European Computer Manufacturer's Script. 

Electronic Commerce. 

Enterprise Data Access/Structured Query Language. 

Enhanced Data Rates for Global Evolution. 

Electronic Data Interchange. 

Electronic Data Interchange for Administration, Commerce 

and Transportation. 

Electronic Funds Transfer. 

Enterprise Information Portal. 

A joint venture between Nokia, Ericsson, Motorola, 

Matsushita, Psion and Symbian for a mobile terminal 

operating system (developed by Symbian). 

Enterprise Resource Planning. 

Food and Beverage. 

Frequency Modulation. 

General Comprehensive Operating Supervisor. 

General Packet Radio System. 

Global System For Mobile Communications. 

Graphical User Interface. 

Health Care Organization. 

Handheld Device Markup Language. 

Health Level 7. 

Human Resources Management System. 

Hypertext Markup Language.

HTTP Hyper-Text Transport Protocol. 

I/O Input/Output. 

IAI Internet Application Integration. 

IBX Internet Business Exchange. 

IDL Interface Definition Language. 

IETF Internet Engineering Task Force. 

HOP Internet Inter-ORB Protocol. 

IM Instant Messaging. 

IP Internet Protocol. 

IPC Interprocess Communication. 

ISP Internet Service Provider. 

ISV Independent Software Vendor. 

LAN Local Area Network. 

LDAP Lightweight Directory Access Protocol. 

LTL Less Than Truckload. 

M-commerce Mobile E-Commerce. 

MOM Message-Oriented Middleware. 

MRO Maintenance, Repair and Operations. 

NFS Network File System. 

NMT Nordic Mobile Telephone. 

OAG Open Applications Group. 

OBI Open Buying on the Internet. 

ODBC Open Database Connectivity. 

OLTP Online Transaction Processing. 

OMG Object Management Group. . 

00 Object-Oriented. 

ORB Object Request Broker. 

ORMS Operating Resource Management System. 

ORMX Operating Resource Management Exchange. 

OS Operating System. 

OTM Object Transaction Manager. 

P2P Peer-To-Peer. 

PC Personal Computer. 

PCS Personal Communications System. 

PDA Personal Digital Assistant. 

PDC Personal Digital Communications. 

PIM Personal Information Manager.


RDF Resource Definition Framework. 

RFQ Request For Quote. 

RIM Research In Motion. 

RMI Remote Method Invocation. 

ROI Return On Investment. 

RPC Remote Procedure Call. 

SCE Supply Chain Execution. 

SCIV Supply Chain Inventory Visibility. 

SCM Supply Chain Management. 

SCP Supply Chain Planning. 

SCS Supply Chain Solutions. 

SFA Sales Force Automation. 

SGML Standardized General Markup Language. 

SI Systems Integrator. 

SIM Subscriber Identification Module. 

SKU Stock-Keeping Unit. 

SMC Supplier-Managed Content. 

SMS Short Message Service. 

SNMP Simple Network Management Protocol. 

SOAP Simple Object Access Protocol. 

SPX/IPX Sequenced Packet Exchange/Internetwork Packet 

Exchange. 

SQL Structured Query Language. 

SSL Secure Sockets Layer. 

TACS Total Access Communication System. 

TCP/IP Transmission Control Protocol/ Internet Protocol. 

TDMA Time Division Multiple Access. 

TMS Transportation Management Systems. 

TP Transaction Processing. 

UNSPSC United Nations Standard Products and Services 

Classification. 

UP Unwired Planet (Former Name Of Phone.Com). 

UPS United Parcel Service. 

URL Universal Resource Locator. 

USB Universal Serial Bus. 

VAN Value-Added Network. 

VoXML Voice Extensible Markup Language.

W3C World Wide Web Coalition. 

WAP Wireless Application Protocol. 

WDP Wireless Data Protocol. 

WML Wireless Markup Language. 

WMLScript Scripting Wireless Markup Language. 

WTLS Wireless Transmission Layer Security. 

xCBL XML Common Business Library. 

XML Extensible Markup Language.


Appendix A 

493


R^SLTTANET 

ungua tranca f or- eBusmess 

PIP SPECIFICATION 

CLUSTER 2: PRODUCT INTRODUCTION 

SEGMENT A: PREPARATION FOR DISTRIBUTION 

PIP2A1 : DISTRIBUTE NEW PRODUCT 

INFORMATION

Table of Contents 

Appendix A 495 

1. Document Management 497 

1.1. Legal disclaimer 497 

1.2. Copyright 497 

1.3. Trademarks 497 

1.4. Acknowledgments 497 

1.5. Prerequisites 497 

1.6. Related documents 498 

1.7. Document version history 498 

2. Introduction 499 

3. Business Operational View 500 

3.1. Business process definition 500 

3.2. PIP purpose 501 

3.3. PIP business process flow diagram 501 

3.4. PIP start state 501 

3.5. PIP end states 502 

3.6. Partner role descriptions 502 

3.7. Business process activity controls 502 

3.8. PIP business information 503 

3.8.1. PIP business documents 503 

3.8.2. Business data entities 504 

4. Functional Service View 505 

4.1. Network component design 505 

4.1.1. Business data entities 505 

4.1.2. Network component specification 506 

4.2. Business action and business signal specification 506 

4.3. Business transaction dialog specification 507 

4.3.1. Distribute new product information dialog: 

service-service 508 


service-service-agent 509 


service-agent-service 510


43.4. Distribute new product resources dialog: 


4.3.5. Distribute new product resources dialog: 

service-service-ageent 512 


service-agent-service 513 

5. Implementation Framework View 515 

5.1. Distribute new product information dialog: 





service-agent-service 516 

5.4. Distribute new product resource dialog: 





service-agent-service 517

1. Document Management 

1.1. Legal disclaimer 


The draft specifications set forth herein are for discussion purposes 

only. This is a working document and is not intended for commercial 

use or public dissemination. Neither RosettaNet nor its members shall 

be responsible for any loss resulting from any use of this document or 

the specifications herein. 

1.2. Copyright 

©1999 RosettaNet. All rights reserved. No part of this publication may 

be reproduced, stored in a retrieval system, or transmitted, in any form 

or by any means, electronic, mechanical, photocopying, recording, or 

otherwise, without the prior written permission of the publisher. Printed 

in the United States of America. 

1.3. Trademarks 

In the best effort, all terms mentioned in this document that are known 

to be trademarks or registered trademarks have been appropriately 

recognized in the first occurrence of the term. 

1.4. Acknowledgments 

This document has been prepared by Edifecs Commerce (http:// 

www.edifecs.com, http://www.CommerceDesk.com) from requirements 

gathered during the cluster/segment workshops and in conformance 

with the RosettaNet methodology. 

1.5. Prerequisites 

The audience should be familiar with the RosettaNet User's Guide, 

"Understanding a PIP Blueprint." This document can be downloaded 

from the RosettaNet EConcert Document Library at the following 

web address.


http://www.rosettanet.org/usersguides/ 

1.6. Related documents 

• Associated PIP Message Guidelines (included with PIP Blueprint and 

PIP Specification) 

• Associated PIP Message Schemas (included with PIP Specification 

only) 

• RosettaNet Technical Dictionaries 

http://www.rosettanet.org/techdictionaries/ 

• RosettaNet Business Dictionary 

http://www.rosettanet.org/businessdictionary/ 

1.7. Document version history 

Version Date PIP Specification Development 

Release 1.0 14 Nov 1999 RosettaNet: Approved Standard 

authorized for publication. 

Version unchanged 2 Jun 2000 Edifecs Commerce: Updated URLs 

in Prerequisites and Related Docs 

sections

2. Introduction 


A Partner Interface Process (PIP) Specification comprises the following 

three views of the eBusiness PIP model. 

1. Business Operational View (BOV). Captures the semantics of 

business data entities and their flow of exchange between roles as 

they perform business activities. The content of the BOV section is 

based on the PIP Blueprint document created for RosettaNet's business 

community. 

2. Functional Service View (FSV). Specifies the network component 

services and agents and the interactions necessary to execute PIPs. 

The FSV includes all of the transaction dialogs in a PIP Protocol. 

The purpose of the FSV is to specify a PIP Protocol that is 

systematically derived from the BOV. The two major components 

within the FSV are the network component design and network 

component interactions. 

3. Implementation Framework View (IFV). Specifies the network 

protocol message formats and communications requirements between 

peer-protocols supported by network components in the RosettaNet 

Implementation Framework. These messages are exchanged when 

software programs execute a PIP; RosettaNet distributes these as 

XML Message Guidelines.


3. Business Operational View 

3.1. Business process definition 

Using this PIP to distribute new product information to partners in the 

supply chain has a number of advantages. 

1. The time to add new products to partner sales catalogs decreases, 

and the time to prepare for promotion and sales in the supply chain 

can be shortened. 

2. There is a reduction in the cost of creating and maintaining sales 

catalogs and configuration engines. 

3. Buyers are notified of new product announcements in a timely 

manner so that they can create SKUs (Stock Keeping Units) for 

products in time to take customer orders. 

Information is distributed to partners as both structured and unstructured 

information. Unstructured information is used to notify employees (e.g., 

buyers) of new products introduced into the supply chain. A receiving 

partner can send this information to employees internally using a mail 

service or workflow system. Structured information, called resources 

(also known as assets), is used to replicate product technical information 

so that a partner can integrate structured information from all supplier 

catalogs into the partner's own electronic catalogs. 

Two categories of structured product information are listed below. 

1. Sales catalog information typically used to promote products to nontechnical 

customers. Sales catalog information can include quantities, 

prices and marketing information. 

2. Technical specifications that are used to promote products to technical 

products and to create content for configuration catalogs. Technical 

specifications only comprise the qualitative and quantitative properties. 

Product information is typically exchanged with partners who have 

subscribed for new announcements.

3.2. PIP purpose 


The purpose of this PIP is to specify the process for distributing new 

product information to Buyers so that enterprise systems can be 

established to accept product orders, and for product information users 

to populate the Buyer's online sales catalogs. 

3.3. PIP business process flow diagram 

- Product Information Distributior - 

Subscription. 

DistributionFormat 

Unstructured 

? 

v ~^> What is Distribution Format ? 

I Subscription.DistributionFormat 

I = Structured 

f 

I Distribute New Product 

_ ~~r 

Success Fail 

l l 

O End Failed O 

 

Product Resource 

Update 

\ 

Distribute New Product ) 

Information y 

Success 

I 

O 

End 

Fail 

\ 

G 

Failed 

3.4. PIP start state 

C 

Product Resource 

[^ Notification 

- Product 

Information 

User- 

Process New^ 

Product 

Resources j 

Figure 3.1. Distribute new product information 

The start state is comprised of the following conditions: 

• Distribution address exists. 

• New product information exists. 

• New product resources exist. 

• Buyer - 

Process 

Product 

Information


3.5. PIP end states 

End states are comprised of one or more conditions: 

END 

• Acknowledgement of receipt exists. 

FAILED 

• The "Notification of Failure" PIP has been executed. (This a 

RosettaNet convention.) 

• Acknowledgement of receipt does not exist. 

3.6. Partner role descriptions 

Table 3.1 describes the activities performed by each role in this PIP. 

Role Name 

Product Information 

Distributor 


User 

Buyer 

Table 3.1. Partner role descriptions 

Role Description 

The partner role that distributes new 

product information to product 

information users and buyers. 

The partner role that uses received 

product information to create online sales 

catalogs. 

An employee that buys products for a 

partner type in the supply chain. 

3.7. Business process activity controls 

Role Type 

Organizational 

Organizational 

Functional 

Table 3.2 describes the interaction contract between roles performing 

business activities in this PIP. 

Table 3.3 details the security, audit and process controls relating to 

activities performed in the PIP.

Role 

Name 

Product 

Information 


Product 

Information 


Role 

Name 

Product 

Information 


Product 

Information 


Activity Name 

Distribute New 

Product 

Information 

Distribute New 

Product 

Resources 

Table 3.2. Business activity descriptions 

Activity Description 

Activity distributes new 

product information to 

buyers in the supply 

chain. 

Activity distributes new 

product resources to 

product information users 

in the supply chain. 

Preconditions 

Distribution 

address is 

provided. 

New product 

information is 

provided. 

Distribution 

address is 

provided. 

New product 

resources are 

provided. 

Table 3.3. Business activity performance controls 

Activity 

Name 

Distribute 

New Product 

Resources 

Distribute 

New Product 

Information 

Acknowledgment 

of Receipt 

Non-Repudiation 

Required? 

N 

N 

Time to 

Acknowledge 

2hr 

2hr 

3.8. PIP business information 

3.8.1. PIP business documents 

Time to Acknowledge 

Acceptance 

N/A 

N/A 

Time to Perform 

2hr 

2hr 

Retry Count 

3 

3 


Post-Conditions 

Acknowledgement 

of receipt is 

received. 


of receipt is 

received. 

Is Authorization 

Required? 

N 

N 

Non-Repudiation 

of Origin and' 

Content? 

Business documents listed in Table 3.4 are exchanged by roles performing 

activities in this PIP. The business documents can be downloaded from 

N 

N


Business Document 

Product Resource Update 

Product Information Notification 

Table 3.4. PIP business documents 

Description 

A product resource update contains structured 

technical information or sales catalog 

information for updating online sales catalogs 

and enterprise systems. 

A product information notification contains 

unstructured sales catalog information. 

the RosettaNet business document repository using the Uniform Resource 

Locator (URL) specified in Section 1.6, 'Related Documents'. 

3.8.2. Business data entities 

The business data entities, fundamental business data entities, and 

global identifying properties can be found in the RosettaNet business 

dictionary using the URL specified in Section 1.6, 'Related Documents'. 

Business data entity security 

There are no security controls specified for this PIR

4. Functional Service View 


The two major components in the FSV are the network component 

design and possible network component interactions, listed in Sections 

4.1 and 4.3. 

4.1. Network component design 

A network component design specifies the network components necessary 

to execute the PIP and the network component collaboration. A network 

component design is comprised of Agent components and Business 

Service components that enable roles to perform business activities in a 

networked environment. Network components collaborate by exchanging 

business action messages and business signal messages. 

4.1.1. Network component collaboration 

Figure 4.1 specifies the network components and their message exchange. 

Buyer 



1. Product Information 2. Product Resource 

Notification Update 


User 

Figure 4.1. — Distribute new product information


4.1.2. Network component specification 

Each network component maps onto a role in the BOV of the PIP 

model. Table 4.1 specifies the mapping between roles in the BOV and 

network components in the FSV. 

4.2. Business action and business signal specification 

Each business action maps onto a Business Document in the BOV of 

the PIP model. Table 4.2 specifies the mapping between Business 

Documents in the BOV and business actions in the FSV. 

Network Component 

in FSV 

Buyer Agent 

Buyer Service 


User Agent 


User Service 


Distributor Agent 


Distributor Service 

Table 4.1. Network component specification 

Classification 

Agent 

Business Service 

Agent 


Agent 


Buyer 

Buyer 

Maps to Role in BOY 

Product Information User 

Product Information User 

Product Information Distributor 


Table 4.2. Business action — business document mapping 

Business Action in FSV 

Product Information Notification Action 

Product Resource Update Action 

Maps To Business Document 

in BOV 

Product Information Notification 

Product Resource Update

4.3. Business transaction dialog specification 


Each business activity between roles in the BOV is specified as a 

business transaction dialog between network components. There are 

two fundamental network components modeled in the Functional Service 

View. 

1. Service network component. Implements protocols that include the 

service layer, transaction and action layer. A service has 'network 

identity' as a business service. The service has an identity URI that 

can be registered in directories and used for component communication 

in a distributed computer system. 

2. Agent network component. Implements protocols that include the 

action layer and the agent layer. There is no service layer or transaction 

layer. 

The FSV allows the following network component interaction 

configurations. 

1. Agent-Service interaction configuration. An agent can request 

service from a service component and a service can respond to the 

request. Agents cannot respond to requests for service. 

2. Service-Service interaction configuration. There can be any number 

of services between end-point services, but no agents. Services both 

provide services to agents and other requesting services as well as 

requesting services for other services. 

3. Agent-Agent interaction configuration. One agent can transfer an 

action to another agent. 

From these three interaction configurations it is possible to derive three 

additional network-component configurations specific to a trading partner 

agreement. 

1. Service-Agent-Service interaction configuration. Services interact 

using two or more agents as a bridge. This configuration is typical in 

configurations where the two services do not know each other's 

identity, or when an employee must include additional private 

information to an action that is sent to another service.


2. Service-Service-Agent interaction configuration. The second service 

acts as a mailbox for the agent. 

3. Agent-Service-Service interaction configuration. A service-toservice 

transaction is a sub-transaction of a larger agent-service 

transaction. 

The rest of Section 4.3 specifies the network component configurations 

possible for this PIP. Each figure specifies the message exchange 

sequence as network components collaborate to execute this PIP. Each 

table shows the properties for each of the messages exchanged by the 

interactions in the corresponding figure. 


service-service 



1. request (ProductlnformationNotificationAction) 

1.1 signal (ReceiptAcknowledgement) 

Buyer Service 

Figure 4.2. — Distribute new product information interactions: service-service


Table 4.3. Message exchange controls — distribute new product information 

1. 

# 

1.1 

Name 

Product 

Information 

Notification 

Action 

Receipt 



Receipt Signal 

2hr 

N/A 


Acceptance Signal 

N/A 

N/A 

Time to Respond to 

Action 

N/A 

N/A 

Included in Time to 

Perform 

Y 

Y 


Required? 


service-service-agent 



1. request (ProductlnformationNotificationAction) 

• 2. 

1.1 signal (ReceiptAcknowledgement) 

N 

N 

Is Non-Repudiation 

Required? 

N 

N 

Is Secure Transport 

Required 

Buyer Service Buyer Agent 

callTxn() 

2.1. return() 

Figure 4.3. — Distribute new product information interactions: service-serviceagent 

0 

Y 

Y



1. 

# 

1.1 

Name 

Product 

Information 

Notification 

Action 

Receipt 




2hr 

N/A 



N/A 

N/A 


Action 

N/A 

N/A 


Perform 

Y 

Y 


Required? 


service-agent-service 



1. callTnx() 

1.1 return 

(Productlnformation 

NotificationAction) 


Distributor Agent 

1.1.1. transfer 



1.1.1.1.1. signal 

(ReciptAcknowledgement) 

Buyer Agent 

N 

N 


Required? 

1.1.1.1. request 



N 

N 


Required 

Y 

Y 

Buyer Service 

Figure 4.4. — Distribute new product information interactions: service-serviceagent



1.1 

# 

1.1.1. 

1.1.1.1. 

1.1.1.1.1. 

Name 

Product 

Information 

Notification 

Action 

Product 

Information 

Notification 

Action 

Product 

Information 

Notification 

Action 

Receipt 




2hr 

N/A 

N/A 

N/A 



N/A 

N/A 

N/A 

N/A 


Action 

N/A 

N/A 

N/A 

N/A 


Perform 

Y 

Y 

Y 

Y 


Required? 



N/A 

N/A 

N 

N 


Required? 

N/A 

N/A 

N 

N 


Required 

Figure 4.5. — Distribute new product resources interactions: service-service 

Y 

Y 

Y 

Y


Table 4.6. Message exchange controls — distribute new product resources 

1. 

# 

1.1 

Name 

Product 

Resource 

Update Action 

Receipt 




2hr 

N/A 



N/A 

N/A 


Action 

N/A 

N/A 


Perform 

Y 

Y 


Required? 




Service 

1. rpquest(:ProductResourceUpdateActiori) 

1.|1. signal( :ReceiptAcknowledgementj) 

N 

N 


Required? 

N 

N 


Required 

: Product Information User I : Product Information 

Service j User Agent 

2. callTxn() 

2.1. returnQ 

Figure 4.6. — Distribute new product resources interaction: service-serviceagent 

^ 

Y 

Y



1. 

# 

1.1 

Name 

Product 

Resource 

Update Action 

Receipt 




• 



2hr 

N/A 

N/A 

N/A 


Action 

N/A 

N/A 


Perform 

Y 

Y 


Required? 



-. Product Information Distributor : Product Informati 

Agent 

r 

.: Product Information • 

User Agent . 

N 

N 


Required? 

N 

N 


Required 

Y 

Y 

: Produci Informati 

User Service 

1.1. return(:ProductResourceUpdateActii 

1. transfer(:ProductResourceUpdati[Action) 

p.- , 1.1.1.1. request(:ProductfiesourceUpdi iteAction) 

1.1.1.1.1. signal(:ReceiptAcknowledgement) 

Figure 4.7. — Distribute new product resources interations: service-serviceagent



1.1 

# 

1.1.1. 

1.1.1.1. 

1.1.1.1.1. 

Name 

Product 

Resource 

Update Action 

Product 

Resource 

Update Action 

Product 

Resource 

Update Action 

Receipt 




2hr 

N/A 

N/A 

N/A 



N/A 

N/A 

N/A 

N/A 


Action 

N/A 

N/A 

N/A 

N/A 


Perform 

Y 

Y 

Y 

Y 


Required? 

N/A 

N/A 

N 

N 


Required? 

N/A 

N/A 

N/A 

N 


Required 

Y 

Y 

Y 

Y

5. Implementation Framework View 


The tables in Section 5 specify the business messages and their 

communications requirements for executing this PIP. 



1. 

1.1 

# 

Table 5.1. Business message and communications specification 

Business Message Guideline 

Product Information Notification Guideline 

Receipt Acknowledgement Guideline 



1. 

1.1 

# 

Digital Signature 

Required? 





N 

Y 


Required? 

Y 

Y 

SSL Required? 

Y 

Y 

SSL Required? 

Y 

Y


5.3. Distribute new product information diaiog: 


1. 

2. 

3. 

4. 

# 









1. 

1.1 

# 


Required? 





Y 

Y 

Y 

Y 


Required? 

Y 

Y 

K; SSL Required? 

1 

Y 

Y 

Y 

SSL Required? 

Y 

Y



1. 

1.1 

# 




Product Resource Update Guideline 




1. 

2. 

3. 

4. 

# 


Required? 




Receipt Resource Update Guideline 



Y 

Y 


Required? 

Y 

Y 

Y 

Y 

SSL Required? 

Y 

Y 

SSL Required? 

Y 

Y 

Y 

Y


Appendix B 

519


© COPYRIGHT 2000 BY ARIBA, INC., INTERNATIONAL BUSINESS MACHINES CORPORATION 

AND MICROSOFT CORPORATION. 

ALL RIGHTS RESERVED. 

UDDI Technical White 

Paper 

September 6, 2000 

SEPTEMBER 6, 2000 PAGE 1 

© COPYRIGHT 2000 BY ARIBA, INC., INTERNATIONAL BUSINESS MACHINES CORPORATION 

AND MICROSOFT CORPORATION. 

ALL RIGHTS RESERVED.

Appendix B 521 

Note: Only parts of the paper have been reproduced verbatim here. The 

contents have been formatted to be consistent with the book style. 

Technical Overview 

The Universal Description, Discovery and Integration (UDDI) 

specifications consist of an XML schema for SOAP messages, and a 

description of the UDDI API specification. Together, these form a base 

information model and interaction framework that provides the ability 

to publish information about a broad array of Web services. 

Four Information Types 

The core information model used by the UDDI registries is defined in 

an XML schema. XML was chosen because it offers a platform-neutral 

view of data and allows hierarchical relationships to be described in a 

natural way. The emerging XML schema standard was chosen because 

of its support for rich data types as well as its ability to easily describe 

and validate information based on information models represented in 

schemas. 

The UDDI XML schema defines four core types of information that 

provide the kind of information that a technical person would need to 

know in order to use a partner's Web services. These are: business 

information; service information, binding information; and information 

about specifications for services. 

The information hierarchy and the key XML element names that are 

used to describe and discover information about Web services are 

shown in Figure 1. 

Business Information: The businessEntity Element 

Many partners will need to be able to locate information about your 

services and will have as starting information a small set of facts about 

your business. Technical staff, programmers or application programs 

themselves will know either your business name or perhaps your business 

name and some key identifiers, as well as optional categorization and


BusinessEntity: Information about the 

party who publishes information about a 

service 

businessService: Descriptive 

information about a particular 

family of technical services 

M 

bindngTempi ate: Technical 

information about a service entry 

point and construction ^Dedications 

Figure 1. — 

| tModei: Descriptions of specifications 

' fo r se rvices o r taxon om i es. Ba sis for 

techn ica I fi n gerp rints 

bindingTemplate data contains references 

totModels, These references designate the 

interface specifieationsfor a service. 

contact information. The core XML elements for supporting, publishing 

and discovering information about a business — the UDDI Business 

Registration — are contained in a structure named 'businessEntity.' 

This structure serves as the top-level information manager for all of the 

information about a particular set of information related to a business 

unit. 

The overall businessEntity information includes support for 'yellow 

pages' taxonomies, so that searches can be performed to locate businesses 

who service a particular industry or product category, or who are 

located within a specific geographic region. 

Service Information: The businessService and 

bindingTemplate Elements 

Technical and business descriptions of Web services — the 'green 

pages' data — live within substructures of the businessEntity information. 

Two structures are defined: businessService and bindingTemplate. The 

businessService structure is a descriptive container that is used to group 

a series of related Web services related to either a business process or 

category of services. Examples of business processes that would include 

related Web service information include purchasing services, shipping 

services, and other high-level business processes.


These businessService information sets can each be further categorized 

— allowing Web service descriptions to be segmented along combinations 

of industry, product and service or geographic category boundaries. 

Within each businessService live one or more technical Web service 

descriptions. These contain the information that is relevant for application 

programs that need to connect to and then communicate with a remote 

Web service. This information includes the address to make contact 

with a Web service, as well as support for option information that can 

be used to describe both hosted services and services that require 

additional values to be discovered prior to invoking a service. Additional 

features are defined that allow for complex routing options such as load 

balancing. 

Specification Pointers and Technical Fingerprints 

The information required to actually invoke a service is described in the 

information element named bindingTemplate. This was described in the 

previous section. However, it is not always enough to simply know 

where to contact a particular Web service. For instance, if I know that a 

business partner has a Web service that lets me send them a purchase 

order, knowing the URL for that service is not very useful unless I 

know a great deal about what format the purchase order should be sent 

in, what protocols are appropriate, what security is required, and what 

form of response will result after sending the purchase order. Integrating 

all parts of two systems that interact via Web services can become 

quite complex. 

As a program or programmer interested in specific Web services, 

information about compatibility with a given specification is required to 

make sure that the right Web service is invoked for a particular need. 

For this reason, each bindingTemplate element contains a special element 

that is a list of references to information about specifications. Used as 

an opaque set of identifiers, these references form a technical fingerprint 

that can be used to recognize a Web service that implements a particular 

behavior or programming interface. 

In our purchase order example, the Web service that accepts the 

purchase order exhibits a set of well-defined behaviors if the proper 

document format is sent to the proper address in the right way. A UDDI


registration for this service would consist of an entry for the business 

partner, a logical service entry that describes the purchasing service, 

and a bindingTemplate entry that describes the purchase order service 

by listing its URL and a reference to a tModel. 

These references are actually the keys that can be used to access 

information about a specification. Called 'tModels,' this information 

is metadata about a specification, including its name, publishing 

organization, and URL pointers to the actual specifications themselves. 

In our example, the tModel reference found in the bindingTemplate is a 

pointer to information about the specifics of this purchase order Web 

service. The reference itself is a pledge by the company that exposes 

the Web service that they have implemented a service that is compatible 

with the tModel that is referenced. In this way, many companies can 

provide Web services that are compatible with the same specifications. 

The Programmer's API 

The UDDI specifications include definitions for Web service interfaces 

that allow programmatic access to the UDDI registry information. The 

full definition of the programmer's API is found in the Programmer's 

API Specification document. The API capabilities are briefly discussed 

below. The API is divided into two logical parts. These are the Inquiry 

API and the Publishers' API. The Inquiry API is further divisible into 

two parts — one part used for constructing programs that let you search 

and browse information found in a UDDI registry, and another part that 

is useful in the event that Web service invocations experience failures. 

Programmers can use the Publishers API to create rich interfaces for 

tools that interact directly with a UDDI registry, letting a technical 

person manage the information published about either a businessEntity 

or a tModel structure. 

Built on SOAP 

The Simple Object Access Protocol (SOAP) is a W3C draft note 

describing a way to use XML and HTTP to create an information 

delivery and remote procedure mechanism. Several companies, including


IBM, Microsoft, DevelopMentor and Userland Software, submitted 

this draft note to the W3C for the purpose of, among other things, 

standardizing RPC (simple messaging) conventions on the World Wide 

Web. In its current state, the draft note describes a specification that is 

useful for describing a Web service. The companies that collaborated 

on UDDI decided to base the UDDI APIs on this SOAP specification. 

The specifics of how SOAP and XML are used by UDDI registry 

Operators are defined in the appendices in the API specification itself. 

All of the API calls defined by the UDDI Programmer's API 

Specification behave synchronously — and all of the distributed UDDI 

registry Operator Sites support all of the calls described in the 

Programmer's API Specification. 

The Inquiry API 

The Inquiry API consists of two types of calls that let a program 

quickly locate candidate businesses, Web services and specifications, 

and then drill into specifics based on overview information provided in 

initial calls. The APIs named fi.nd._xx provide the caller with a broad 

overview of registration data based on a variety of search criteria. 

Alternately, if the actual keys of specific data are known ahead of time, 

up to date copies of a particular structure (e.g., businessEntity, 

businessService, bindingTemplate, tModel) can be retrieved in full via a 

direct call. These direct calls are called the get_xx APIs. 

The UDDI Invocation Model 

Each individually advertised Web service is modeled in a 

bindingTemplate structure. Invocation of a Web service is typically 

performed based on cached bindingTemplate data. With this in mind, 

the general scenario for using UDDI becomes clear when you consider 

the preparation required to write a program that uses a specific Web 

service. The following outlines these steps: 

1. The programmer, chartered to write a program that uses a remote 

Web service, uses the UDDI business registry (either via a Web 

interface or other tool that uses the Inquiry API) to locate the


businessEntity information registered by or for the appropriate business 

partner that is advertising the Web service. 

2. The programmer either drills down for more detail about a 

businessService or requests a full businessEntity structure. Since 

businessEntity structures contain all information about advertised 

Web services, the programmer selects a particular bindingTemplatelO 

and saves this for later use. 

3. The programmer prepares the program based on the knowledge of 

the specifications for the Web service. This information may be 

obtained by using the tModel key information contained in the 

bindingTemplate for a service. 

4. At runtime, the program invokes the Web service as planned, using 

the cached bindingTemplate information (as appropriate). In general, 

assuming the remote Web service and the calling program each 

accurately implement the required interface conventions (as defined 

in the specification referenced in the tModel information), the calls 

to the remote service will function successfully. The special case of 

failures and recovery is outlined next. 

Recovery After Remote Web Service Call Failure 

One of the key benefits of maintaining information about Web services 

in a distributed UDDI Registry is the 'self service' capability provided 

to technical personnel. The steps in the previous section outlined the 

tasks that the programmer is able to accomplish using the information 

found in the UDDI registry. 

This is all fine and well, but additional benefits are possible. These 

benefits of using a distributed UDDI registry with information hosted at 

an Operator Site are manifested in disaster recovery scenarios. 

Web services businesses using Web services to do commerce with 

their partners need to be able to detect and manage communication 

problems or other failures. A key concern is the inability to predict, 

detect, or recover from failures within the systems of the remote 

partner. Even simple situations, such as temporary outages caused by 

nightly maintenance or back-ups can make the decision to migrate to 

Web services difficult.


On the other hand, if you are the company that makes direct Web 

service connections possible, disaster recovery and the ability to migrate 

all of your business partners to a back-up system are prime concerns. 

UDDI starts to address these 'quality of service' issues by defining a 

calling convention that involves using cached bindingTemplate 

information, and when failures occur, refreshing the cached information 

with current information from a UDDI Web registry. The steps for this 

convention are as follows: 

1. Prepare program for Web service, caching the required 

bindingTemplate data for use at run-time. 

2. When calling the remote Web service, use the cached bindingTemplate 

data that was obtained from a UDDI Web registry. 

3. If the call fails, use the bindingKey value and the get_bindingTemplate 

API call to get a fresh copy of a bindingTemplate for this unique 

Web service. 

4. Compare the new information with the old — if it is different, retry 

the failed call. If the retry succeeds, replace the cached data with the 

new data. 

Behind the scenes, when a business needs to redirect traffic to a new 

location or backup system, they only need to activate the backup system 

and then change the published location information for the affected 

bindingTemplates. This approach is called retry on failure and is more 

efficient than getting a fresh copy of bindingTemplate data prior to 

each call. 

The Publication API 

The Publication API consists of four sove_xx functions and four delete_xx 

functions, one each for the four key UDDI data structures (businessEntity, 

businessService, bindingTemplate, tModel). Once authorized, an individual 

party can register any number of businessEntity or tModel information 

sets, and can alter information previously published. The API 

design model is simple — changes to specific related information can 

be made and new information saved using save. Complete structure 

deletion is accommodated by the delete calls.


Security: Identity and Authorization 

The key operating principal for the UDDI Publishers' API is to only 

allow authorized individuals to publish or change information within 

the UDDI business registry. Each of the individual implementations of 

the distributed UDDI business registry maintains a unique list of 

authorized parties and tracks which businessEntity or tModel data was 

created by a particular individual. Changes and deletions are only 

allowed if a change request (via API call) is made by the same 

individual who created the affected information. 

Each instance of a UDDI business registry, called an Operator Site, 

is allowed to define its own end user authentication mechanismll, but 

all of the contracted UDDI Operator Sites are required to meet certain 

minimum criteria that provide similar security protections. 

For more details on the UDDI schema or the UDDI Programmer's 

API Specification, consult the documents that are available on the 

uddi.org Web site. 

These specifications are published as a set of linked HTML 

documents, with specific tModels defined for related sub service 

offerings. The individual tModel references are actually overview 

information with shared links to overview, API call, and appendix 

information within the overall specification.

Appendix A: UDDI Information Model 


The diagram below shows the relationships between the different core 

information elements that make up the UDDI information model. 

businessEntity 

BusinessKey 

name 

description 

bu si nessS ervi ces 

categoryBag 

identifier Bag 

0..n i 0. ,1 

LJ 

businessService 

seiviceKey 

businessKey 

name 

description 

bi nd in gTernpl ates 

categoryBag 

0..n 

bi nd in gTemp! ate 

bindingKey 

serviceKey 

description 

accessPoint 

0..1 

hosti n gRed ir eetor 

.0..1 

a.n 

" 

identifierBag 

categoryBag 

Figure 2. — 

1., n


Resources 

This section contains the locations of various specifications, document 

references and useful information where you can learn more about this 

subject. 

• W3C XML and related recommendations: http://www.w3.org/TR 

• SOAP 1.1 W3C note: http://www.w3.Org/TR/#Notes 

• UDDI Web site: http://www.uddi.org 

• UDDI Programmer's API Specification: 

http://www.uddi.org/pubs/UDDI_Programmers_API_Specification.pdf 

• UDDI Data Structure Reference: 

http://www.uddi.org/pubs/UDDI_XML_Structure_Reference.pdf 

• UDDI Revision 1.0 schema: http://www.uddi.org/schema/uddi_l.xsd

Bibliography 

1. Atkins D.E. et al., 'Toward Inquiry-Based Education Through 

Interacting Software Agents', University of Michigan Publication, 

(2000). 

2. Atkinson H., 'The Evolution of NTE', JOC Week, (February 2001). 

3. Babcock C, 'RosettaNet Gets Businesses to Talk in XML', 

Inter@ctive Week — ZdNet, (October 2000). 

4. BadBlue, 'A Standards-based, P2P Approach to Marketplaces and 

Exchanges', BadBlue Position Paper, (February 2001). 

5. Baker S., CORBA Distributed Objects: Using Orbix (Addison- 

Wesley, 1997). 

6. Balasubramanian S. and Norrie D.H., 'A Multi-Agent Intelligent 

Design System Integrating Manufacturing And Shop-Floor Control', 

Division of Manufacturing Engineering Publication, (Department 

of Mechanical Engineering, University of Calgary, 2001). 

7. Baldwin CM., 'Data Integration Software Speeds Web', Network 

World, (November 2000). 

8. Barlas D., 'Collaborative As Marketplace Planned', Line56, (January 

2001). 

9. BEA Systems, 'Future-Proof Your Business with the BEA 

WebLogic E-business Platform', BEA.com, (April 2001). 

10. BEA Systems, 'Enterprise Application Integration (EAI) Providing 

Stability in a Whirlwind of E-Commerce', BEA.com, (May 2000). 

11. BEA Systems, 'Proposal for Business Transaction Protocol — 

Version 1.0', BEA.com, (March 2001). 

12. Berryman K. and Heck S., 'Is The Third Time The Charm For 

B2B?', Internet Week, (March 2001). 

13. Bharat A.K. and Cardelli L., 'Migratory Applications', SRC 

Research Report, (February 1996). 

531


14. Boardman R., An XML/XSL Architecture for Language-neutral 

Document Authoring, Translation and Online Publishing (Centre 

for Cognitive Science, Edinburgh University, UK, 1999). 

15. Bois G.D. and McCright J.S., 'Exchanges turning to P2P platforms', 

eWeek, (March 2001). 

16. Bonde A., 'Building An E-biz Strategy', PlanetIT, (August 2000). 

17. Bosak J., 'XML — Questions & Answers', Sun Microsystems 

Publication, (1999). 

18. Breithaupt J. and Merkow M.S., 'The Complete Guide to Internet 

Security (Juillet)\ (2000). 

19. Britton C, IT Architectures and Middleware: Strategies for Building 

Large, Integrated Systems (Addison-Wesley, 2000). 

20. Brown T., Temkin B., Lief V. and McCarthy K., 'Net Marketplaces 

Grow Up', The Forrester Report, (December 1999). 

21. Bryan M., An Introduction to the Extensible Markup Language 

(XML) (The SGML Centre, 1997). 

22. Business Wire, '@YourCommand Introduces New Search Engine 

With Certified Privacy', Business Wire, (October 1998). 

23. Butler S., 'B2B: The Year That Was', eMarketer.com, (December 

2000). 

24. Choi S.Y. and Whinston A.B., 'Is P2P Right for B2B?', Cisco.com, 

(April 2001). 

25. Chung M.H., Lee L. and Turban E., Electronic Commerce — A 

Managerial Perspective (Prentice Hall, 1999). 

26. Chung T.L., Lee J., King D. and Chung H., Electronic Commerce 

— A Managerial Perspective (Prentice-Hall, 1999). 

27. Cover R., 'Web Services Flow Language (WSFL)', XML Cover 

Pages, (June 2001). 

28. Cox J., 'Browserless Web is the future of B2B', Work World, 

(January 2001). 

29. Craig T., 'Supply Chain Management Six Issues That Impact Its 

Effectiveness', A publication of Round Table Group, (August 1998). 

30. Dasgupta P., Narasimhan N., Moser L.E. and Melliar-Smith P.M., 

'A Supplier-Driven Electronic Marketplace Using Mobile Agents', 

Department of Electrical and Computer Engineering Publication, 

(University of California, Santa Barbara, 2001).

Bibliography 533 

31. Davidson J., 'Driving Logistics Online Markets', Traffic World, 

(April 2001). 

32. Dejesus E.X., 'EDI? XML? Or Both?', Computer World, (January 

2001). 

33. Dhawan R.K. et al., 'The Asian difference in B2B', The McKinsey 

Quarterly Number 4 Asia, (2000). 

34. Draenos S., 'The b-to-b chameleons', Upside Magazine, (May 

2001). 

35. Drakos N., 'P2P Networks: One Step Forward, Two Steps Back?', 

Gartner Group Publication, (April 2001). 

36. Dumbill E., 'XML, Standards and You', Xml.com, (April 2000). 

37. EAI Journal, 'Extricity Software Solution for Adaptec — Best 

E-business Solution', EAI Journal, (2000). 

38. ebXML.org, 'Business Process and Business Information Analysis 

Overview vl.0.', ebXML.org, (May 2001). 

39. Eichmann D., 'Ethical Web Agents', Repository Based Software 

Engineering Program Research Institute for Computing and 

Information Science, (University of Houston, 2000). 

40. Einsiedler H.J. and Gleizes M.P., 'ABROSE: A Co-operative Multi- 

Agent Based Framework for Electronic Marketplace', France 

Telecom CNET Publication, (Univ. Toulouse, 1998). 

41. Enslow B., 'Managing Visibility to Improve Supply Chain Performance', 

Software Solutions Business World Conference., (2000). 

42. Enslow B., 'The Internet's effect on Supply Chain Power', 

Achieving Supply Chain Excellence through Technology (ASCET), 

(2000). 

43. Extricity, 'B2B Integration Overview', Extricity.com, (January 

2000). 

44. Extricity, 'Exporing the challenges of B2B Integration', 

Extricity.com, (July 1999). 

45. Fingar P., A CEO's Guide to eCommerce Using Object-Oriented 

Intelligent Agent Technology, (June 1998). 

46. Fluss D. and Knox R., 'Why CRM Executives will Care About 

XML', Gartner Group Publication, (November 1999). 

47. Ford W. and Baum M.S., Secure Electronic Commerce (2nd Ed.), 

(2001).


48. Frawley A., 'Evolving to eCRM: How to Optimize Interactive 

Relationships Between You and Your Customers', Xchange Inc., 

(2001). 

49. Freter T., 'XML: It's the Future of HTML', Sun Microsystems 

Publication, (April 2000). 

50. Freter T., 'XML: Mastering Information on the Web', Sun 

Microsystems Publication, (April 2000). 

51. Gartner Consulting, 'A Model for Determining the Financial 

Benefit of an Integration Broker Implementation', Gartner Group 

Publication, (January 2000). 

52. Ghosh A., E-commerce Security Weak Links, Best Defenses (John 

Wiley & Sons, 1998). 

53. Gisolfi D., 'Web Services Architect, Part 1: An Introduction to 

Dynamic E-business', IBM Publication, (April 2001). 

54. Gomes V.W, 'JXTA: Getting across to your peer', Cyber India 

on-line Limited Publication, (May 2001). 

55. Gong Li, 'Project JXTA: A technology overview', Sun Microsystems 


56. Gonzales M.L., 'A Data Strategy for the Enterprise', DB2 Magazine, 

(Winter 2000). 

57. Grosof B, 'Business Rules for E-Commerce: Interoperability and 

Conflict Handling', IBM T.J. Watson Research Center Publication, 

(2001). 

58. Hackbarth G. and Kettinger W.J., 'Building an E-business Strategy', 

Information Systems Management, (Summer 2000). 

59. Hammer K., 'Data Integrity in E-business', EAI Journal, (2001). 

60. Hau L.L., Whang S. and Padmanabhan V., 'The Bull Whip Effects 

in Supply Chain', Sloan Management Review, (Spring 1997). 

61. Hoffman M., 'How XML Will Redefine the E-Commerce Market', 

CommerceOne.com, (2001). 

62. Horowitz B., 'Managing the Security Risks of Your E-business', 

Ebizq.net, (August 2000). 

63. IBM Corporation, 'B-to-B E-commerce: Offering Suppliers New 

Opportunities to Connect With Buyers', IBM Publication, (May 

2000). 

64. IBM Data Management Group, 'Dynamic e-business with DB2 

and Web Services', IBM Publication, (2001).


65. Kalakota R. and Robinson M., E-business Roadmap for success 

(Addison-Wesley, 1996). 

66. Kasrel B., Bernoff J., Monson E. and Gerson M., 'P2P's Pervasive 

Future', The Forrester Report, (January 2001). 

67. Kay E., 'From EDI to XML', Computer World, (June 2000). 

68. Kennedy S., 'B2B exchanges that failed to deliver', Cyber India 

on-line Limited Publication, (April 2001). 

69. Kestelyn J., 'RosettaNet: Hardly a Dead Language', Intelligent 

Enterprise Magazine — Volume 3, Number 18, (December 2000). 

70. King D., 'Electronic Commerce and Supply Chain Management', 

part of the Internet and the Digital Economy Track of The Thirty 

Third Annual Hawaii International Conference on Systems Sciences 

(HICSS), (2001). 

71. Kohtz D. and Gray R.S., 'Mobile Agents and the Future of the 

Internet', Department of Computer Science Publication, (Thayer 

School of Engineering, Dartmouth College, 2001). 

72. Kotok A., 'XML and EDI Lessons Learned and Baggage to Leave 

Behind', O'Rielly Xml.com, (August 1999). 

73. Lawton G., 'BizTalk, RosettaNet and the Holy Grail of E-commerce 

Integration', eBizQ, (November 2001). 

74. Leibman L., 'EAI Goes B2B', Internet Week, (September 2000). 

75. Lengel K., 'B2B Basics', CIO Magazine, (August 2000). 

76. Lenzmann B., Wachmuth I. and Cao Y., 'An intelligent interface for 

a virtual environment', University of Bielefeld, Faculty of Technology 


77. Leung L., 'Move Over ERP, Here Comes ERP IF, Gartner 

Symposium/ITxpo, (October 2000). 

78. Lewis B., 'Beyond E-mail: Enterprise Integration Issues for Mobile 

E-Commerce', Transactions Marketing Inc. Publication, (2001). 

79. Lheureux B., 'XML will Ultimately Pay for Itself in Application 

Integration', Gartner Group Publication, (June 1999). 

80. Linthicum D.S., B2B Application Integration (Addison-Wesley, 

2001). 

81. Linthicum D.S., Enterprise Application Integration (Addison- 

Wesley, 2000). 

82. Lipis L.J., 'E-marketplaces services profile series', IDC Bulletin 

#22399, (May 2000).


83. Liu S., 'Scanning The Business Environment With Intelligent 

Software Agents', Turku Centre for Computer Science TUCS and 

Institute for Advanced Management Systems Research, (Abo 

Akademi University, Lemminkaisenkatu, Finland, 2000). 

84. Malone R., 'Trading Exchanges Empower Transportation Management', 

Logistics Magazine, (July 2000). 

85. McAfee A., 'The Napsterization of B2B', Harvard Business Review, 

(December 2000). 

86. McCarthy A., Zohar M., Dolan T. and Lee S., 'Mobile Internet 

Platforms Emerge', The Forrester Report, (November 2000). 

87. McCoy D., 'BPMI.org Attempts the Impossible: BPM Standards', 

Gartner Group Publication, (July 2001). 

88. Memishi R., 'B2B Exchanges Survival Guide Introduction', Internet 

Magazine World, (January 2001). 

89. Meredith G., Christensen E. and Weerawarana S., 'Web Services 

Description Language (WSDL) 1.1', w3.org, 2001. 

90. Merkow M, 'B2B, Privacy, and You', Internet.com, (December 

2000). 

91. Merkow M., 'What Can P2P Do For B2B', Redux, (2001). 

92. Merkow M., 'XML at Your Service', Webreference.com, (April 

1999). 

93. Mesher A., 'Supply Chain Evolution Will Require an Integration 

Revolution', Supply Chain Excellence through Technology (ASCET), 

(2000). 

94. Microsoft, 'BizTalk Orchestration, A Technology for Orchestrating 

Business Interactions', Microsoft Publication, (June 2000). 

95. Microsoft, 'BizTalk Server 2000 Product Documentation', Microsoft 


96. Miller E., 'An Introduction to the Resource Description 

Framework', D-Lib Magazine, (May 1998). 

97. Mobilocity, Inc., 'Seizing the M-Commerce Opportunity — 

Strategies for Success on the Wireless Web', Mobilocity.net, 

(April 2000). 

98. Mobilocity, Inc., 'Fundamentals of Mobile Business to Employees 

(B2E) Applications, A Strategic Approach', Mobilocity.net, (January 

2001). 

99. Nelson M. and Holt S., 'RosettaNet Jumps on XML Bandwagon', 

InfoWorld Electric, (June 1999).


100. Net-Centric Consulting Group LLC, 'Business Planning Services', 

Net-centric.net, (2001). 

101. Netfish Technologies, 'XDI EDI Data Sheet', Netfish Publication, 

(2001). 

102. Netscape, 'Integrating Netscape Application Server Solutions With 

Existing Enterprise Systems and Applications', Netscape.com, (July 

1999). 

103. Nordan M. and Favier J., 'Heralds Mobile B2B E-commerce', The 

Forrester Report, December 2000. 

104. Nortel Networks, 'VPNs Tutorial', Nortel Networks Publication, 

(2001). 

105. Nwana S.H., 'Software Agents: An Overview', Intelligent Systems 

Research, Advanced Applications & Technology Department, 

(BT Laboratories, Martlesham Heath Ipswich, Suffolk, September 

1996). 

106. Oliver D.D., 'Agent-Based Decentralized Coordination for Electronic 

Markets', Department of Information Systems Publication, 

(University of Erlangen-Nuremberg Lange Gasse, Germany, 2001). 

107. Olsen G., 'An Overview of B2B Integration', EAI Journal, (May 

2000). 

108. Oracle, 'E-business Integration Architecture', Oracle Magazine, 

(September 2000). 

109. Orfali, R., The Essential Client/Server Survival Guide (2nd Ed.), 

(John Wiley & Sons, 1996). 

110. Paat J., 'Clearinghouse Model Fills Need for B2B Integration', 

BizJournals, (October 2000). 

111. Patsuris' P., 'B2B Exchange Madness', Forbes Magazine, (April 

2000). 

112. Pretson R. and Yasin R., 'Dow's New Chemistry', InternetWeek, 

(July 2000). 

113. Progress Software Corporation, 'Benchmarking E-business 

Messaging Providers', Progress Software Publication, (2001). 

114. Quinn F.J., 'The Payoff Potential in Supply Chain Management', 

Achieving Supply Chain Excellence through Technology (ASCET), 

(2000). 

115. Quinn F.J., 'What's the buzz?', Supply-chain Management 

Report by Logistics Management & Distribution Report, (September 

1997).


116. Radeke M., 'Understanding B2B Online Exchanges', Workz.com, 


117. Ruh W.A. et al., Enterprise Application Integration (A Wiley 

Tech Brief, John Wiley & Sons, 2001). 

118. Rymer J., 'Why 90 Percent of XML Standards will Fail', ZdNet, 

(Feburary 2001). 

119. Sahay B.S., 'Supply Chain Management in the Twenty First 

Century', Twenty-First Century, (Macmillan, 2001). 

120. Sankaran S. and Bui T, 'Software Agents for Telemedicine', 

California State University Northridge Publication, (1999). 

121. Sari K., 'Its' Not Easy Being B2B', CIO Magazine, (October 1999). 

122. Sayeed I., Sabatino G. and Boey P., 'Architecting E-business 

Solutions', 2nd International We-B Conference Proceeding Volume 

II No 7, (2001). 

123. Schmidt J., 'Enabling Next Generation Enterprises', EAI Journal, 

(July 2000). 

124. Schwartz K.D., 'It's a Bad, Bad, Bad, Bad World', CIO Magazine, 

(April 2001). 

125. ScreamingMedia, Tntarka Announces ProspectMiner 1.2 — a 

Powerful Web Mining Solution for Business', Business Wire, 


126. SeeBeyond, 'SeeBeyond E-business Integration Suite Product 

Datasheet', SeeBeyond.com, (2001). 

127. Shankarnarayanan, S., 'ERP Systems — Using IT to Gain a 

Competitive Advantage', Expressindia, (2001). 

128. Shih C, 'The Use of XML in E-Commerce', Gartner Group 

Publication, (May 1999). 

129. Shih C, 'The Use of XML in E-Commerce', Gartner Group 


130. Siegel, J., Ph.D., CORBA 3 Fundamentals and Programming (2nd 

Ed.), (John Wiley & Sons, 2000). 

131. Siepel P. and Borking J.J., 'Intelligent Software Agents: Turning a 

Privacy Threat into a Privacy Protector', Intelligent Software Agents 

and Privacy Conference, The Hague, (1999). 

132. Sinmao M.V., Intelligent Agents and E-Commerce, (November 

1999). 

133. Sohn A., 'Integration Challenge in B2B Commerce', EAI Journal, 

(2001).


134. Sohn A., 'Integration Challenges in B2B Commerce', EAI Journal, 

(2001). 

135. Sprague C. and Kinselia B, 'B2B E-commerce Comes of Age and 

Drives Shareholder Value', Ascet Vol 2, (2001). 

136. Strange K. and Friedman T., 'Why the Virtual Data Warehouse 

Still Won't Work', Gartner Group Publication, (April 2001). 

137. Sundsted T., 'Agents on the move', Javaworld, (July 1998). 

138. Sundsted T., 'An introduction to agents', Javaworld, (June 1998). 

139. Surmacz J., 'One Is Not Enough', CIO Magazine, (May 2001). 

140. Thatte S., 'XLANG, Web Services for Business Process Design', 

Microsoft, (2001). 

141. The Software & Information Industry Association, Building the 

Net: Trends Report, (2000). 

142. Thompson C, 'Agents and e-commerce', ROB Magazine, 


143. Tibco, TIB®/Adapter SDK, A TIBCO ActiveEnterprise Product, 

Adapting Custom Applications into the E-business Infrastructure, 

(2000). 

144. Timme G.S. and Williams-Timme C, 'The Financial SCM 

Connection', Supply Chain Management Review, (2000). 

145. Trudeau R. Jr., 'The Hidden Opportunity in Business-to-Business 

E-Commerce, George Stalk', The Boston Consulting Group, Inc. 


146. Tsvetovat M., Chen Y., Ying J. and Sycara K., 'Customer Coalitions 

in the Electronic Marketplace', Carnegie Melon University 


147. Uchneat J., 'Collaborative E-Commerce: Driving Productivity in 

2000 and Beyond', Achieving Supply Chain Excellence through 

Technology (ASCET) Volume 2, (2000). 

148. UDDI.org, 'Using WSDL in a UDDI Registry 1.02, UDDI Working 

Draft Best Practices Document', UDDI.org, (February 2001). 

149. Ulrich W., 'Business Process Integration: Time to Take a Holistic 

Approach', System Transformation, (2001). 

150. Vogle D., 'SAQQARA: Implementing RosettaNet — a Decision 

that Stands the Test of Time', Link2SemiConductor.com, (October 

2000). 

151. Vollemer K., 'Don't Believe The Hype: EDI And XML Are Just 

Perfect Together', Internet Week, (January 2001).


152. Waltner C, 'B-To-B E-Payment Offers Benefits To Marketplaces', 

Information Week, (November 2000). 

153. Walton B. and Princi M., 'From Supply Chain to Collaborative 

Network: Case Studies in the Food Industry', Achieving Supply 

Chain Excellence through Technology (ASCET), (2000). 

154. Webber D.R.R., Mikula N., Marchal B. and Peat B., 'Guidelines 

for Using XML for Electronic Data Interchange', XML/EDI Group, 

(1998). 

155. webMethods, 'B2B: Launch Any Integration Initiative', 

webMethods.com, (2001). 

156. webMethods, 'Enabling eBusiness Through Enterprise Application 

Integration', webMethods.com, (June 2001). 

157. webMethods, 'Transactional Integrity For E-business Integration', 

webMethods.com, (2001). 

158. webMethods, 'webMethods Enterprise: Scalable Enterprise 

Application Integration', webMethods.com, (2001). 

159. Wegner L., Temkin B. and Kafka S., 'B2B Auctions Go Beyond 

Price', The Forrester Report, (May 2000). 

160. Wellman M.P., 'The Economic Approach to Artificial Intelligence', 

ACM Computing Surveys Symposium on Artificial Intelligence, 

(1995). 

161. White A., 'Introduction to Supply Chain Management', 

Business.com, (February 1995). 

162. Widom J., 'Data Management for XML', IEEE Data Engineering 

Bulletin, Special Issue on XML, 22(3):44-52, (September 1999). 

163. Windley M.V. et al, 'A programming and execution environment 

for distributed multi-agent systems', University of Delaware 


164. Wooldridge M. and Jennings N., 'Intelligent agents: theory and 

practice', The Knowledge Engineering Review, Vol.l0:2, (1995). 

165. XNS.org, 'How Web Agents work: A quick Primer', XNS.org, 


166. Yeamans L., 'Message Brokering, Should You Bet Your Business 

on It?', Ebizq.net, (2001).

24/7 Availability 41, 448, 453 

A2A (application-to-application) 268, 

see application oriented integration 

access control 321 

adapters 30, 117 

administration tool 266 

agent systems 387 

American National Standards Institute 

154 

Application Center Server 2000 241 

Application Programming Interfaces 

see APIs 

application 

adapters 262-263 

broker 82 

oriented integration 25, 49, 74-89, 

255 

APIs 74-82, 104, 339, 460 

classes 77-81 

component/object 79 

components 77-78 

data management 79 

file 80 

messaging 79 

method 78 

application servers 30 

Automator 143 

authentication 292, 309, 338 

authorization 338 


exchanges 34, 42, 130, 441-468 

integration 9-10, see B2Bi 

Index 

541 


standards 20 

transaction 18-19 

wireless 368 

B2Bi 9-10 

and e-marketplaces 459 

challenges 35-41 

components 25-32 

domains 35 

goals 451 

P2P 479-483 

patterns 48-49, see B2Bi, types 

performance and scalability 40 

security risks 292 

SOA 328 

software agents 396 

solution 17-20 

strategy 14-15, 23, 68 

types 25 

XML-based 34 

B2C 6-8, 268 

wireless 368 

B2E 366-369 

back-office processing 105 

BAPI 109 

batch transfer 103 

BEA WebLogic 252-253 

integration 142 

BEA's eLink 115, 252 

BizTalk 148, 179, 189, 207-212 

Envelope 208 

Server 2000 240


BPI see business process oriented 

integration 

BPM see Business Process Management 

BPMI see Business Process 

Management Initiative 

BPML see Business Process Modeling 

Language 

BPQL see Business Process Query 

Language 

BPR see Business Process Reengineering 

broadcasting 222 

business 

models 7 

process automation 137 

process engine 92 

process life cycle 128 

Business Process Management 27, 34, 

74, 89, 120-141, 273 

internal 39 

Business Process Management Initiative 

148-149 

Business Process Modeling Language 

148 

business process oriented integration 25, 

39, 49, 89-92, 104 

patterns 89-90, see Open Processbased 

(Public Process) Integration, 

see Closed Process-based (Private 

Process) Integration 


Query Language 149 

Reengineering 107 

Business Rules For Electronic Commerce 

(BRML) 406 

Business-to-Business see B2B 

Business-to-Consumer see B2C 

Business-to-Employee see B2E 

callback functions 83 

Cascading Style Sheets (CSS) 175 

catalog 202 

management 15, 19 

Catalog Publishing 459 

certificate 301 

authorities (CAs) 300, 318 

server 371 

ciphers 302 

client/server systems 105 

closed process-based (private process) 


collaboration 479, 450 

collaborative 

agents 388, 399 

commerce 466 


networks 42, 428, 462, 464 

Collaborative Partner Agreement (CPA) 

204 

Collaborative Planning and Forecasting 

see CPFR 

COM+ 233, 239-244 

commerce agents 389 

Commerce Extensible Markup Language 

see cXML 

Common Object Request Broker 

Architecture see CORBA 

communication protocols 268 

confidentiality 292 

content management services 454 

CORBA 233, 242 

application interfaces 238 

Component Model (CCM) 

protocol 234 

domains 237 

horizontal facilities 237 

services 236 

CORBA3 235 

CORBA components package 239 

Java and Internet integration 238 

quality of service control 239 

CPFR 7, 433-435 

CRM see Customer Relationship 

Management 

cryptography 293, 311 

Customer Relationship Management 15, 

99, 111-115, 364

customer service 34 

cXML 163, 179, 183, 189, 202-203, 

329 

data oriented integration 25, 49-68, 89, 

103, 255 

B2Bi 49, 67 

XML 66 

data 

protection 338 

replication 50-53, 103 

bi-directional 52 

marts 54, 59-62 

multi-site 53 

primary site 51-52 

transformation 461 

union 103 

warehouses 54, 59-62, 99, 112 

Data Transformation Component 

264-265 

DataMapper 265 

DB2 DataJoiner 64 

DCE see Distributed Computing 

Environment 

DCOM 243 

deliberative agents 388 

De-militarized Zone (DMZ) 312 

denial-of-service attack (DOS) 322 

departmentalized distributed computing 

98 

designer tool 58 

digital certificates 300-301 

envelope 296 

signature 296-299, 301 

Directory Services 269 

Distributed Authoring and Versioning 

Protocol 149, see WebDAV 

distributed client-server systems 98, 105 

computing 141 

control 40 

objects and components 215, 

231-249 

systems 98 

Index 543 

Distributed Computing Environment 87 

Document Type Definition 164, 171, 

181, see XML, DTDs 

Domain Name Service (DNS) 407, 472 

DOMHASH 314 

DTD see Document Type Definition 

EAI 10, 26-27, 71, 96-124 

convergence and divergence with 

B2Bi 121-123 

e-business see e-commerce 

drivers 4 

ebXML 148, 150, 179, 188, 204 

e-commerce 

B2B 5 

collaborative 4, 8, 39 

mobile 345-382, 364 

differences with m-commerce 346 

e-distribution sites see emarketplaces, 

supplier-centric 

e-logistics 429 

e-marketplaces see B2B, exchanges 

agent-based 401 

auction-services 455 

brokered 446 

buyer-centric 444 

credit worthiness 452 

governance 447 

horizontal 443 

liquidity 452 

neutral 445, 449, 453 

on-demand trading 366 

open 445 

pass-through 446 

private 446 

supplier-centric 444 

vertical 443 

e-payment 315 

e-procurement 42, 192, 426-428, 436, 

453, 460 

role of software agents 402 

e-procurement sites see e-marketplaces, 

buyer-centric


eCRM 113-114 

EDIFACT 179 

EDI 154-186, 174 

EJBs 233, 245-249 

Electronic Bill Presentment and Payment 

(EBPP) 457 

Electronic business Markup Language 

see ebXML 

electronic CRM see eCRM 

Electronic Component Technical 

Dictionary (ECTD) 197 

Electronic Data Interchange see EDI 

encryption 301, 309, see cryptography 

private key 294 

public key 295 

Enterprise Application Integration see 

EAI 

enterprise business portals 102 

Enterprise JavaBeans see EJBs 

Enterprise Resource Planning see ERP 

Enterprise Systems 106-115 

entitlements management 312 

entity beans 249 

ERP 99, 106-115 

integration 109 -111 

systems 442, 462 

ERP II 108-109 

ETL 54-59 

ETL Engine 55-57 

event driven integration see business 

process oriented integration 

Extensible Name Service (XNS) 

407-408 

Extensible Markup Language see XML 

Extensible Stylesheet Language 175, 

see XSL 

Extract, Transform and Load Solution 

see ETL 

Extricity B2B Alliance Manager 144 

Fastenal 

XML EDI Case Study 183 

fault tolerant architecture 50 

Financial Information eXchange 

(FIXML) 183 

Financial Products Markup Language 

see FpML 

firewalls 302-307 

application level 305 

enterprise firewall appliance 306 

network level 304 

FpML 163, 183, 188, 200-201, 329 

GARTMORE 

Trade Processing Case Study 

118-120 

handheld device 347, 349, 367, 376, 471 

hash function 297 

host integration server 240 

HTML 157-158 

IBM WebSphere 249-251 

MQ Integrator 118 

IDocs 110 

HOP 242 

HOP protocol 209 

industry standards 

issues 40 

information agents 388, see software 

agents, information gathering 

information gathering 32 

discovery 483 

in-process server 242 

Instant messaging (IM) 348 

integration 

goals 14-16, 93-94 

hub-and-spoke 12-13, 115, 156, 

178, 256 

patterns see B2Bi, patterns 

point-to-point 115, 442, 463 

integration brokers 30-31, 59, 255 

connectivity 271 

hub-and-spoke architecture 256-257 

message bus architecture 257-258 

multi-hub architecture 258-259

integrity 292 

intelligent agents 481, see software agents 

Interface Definition Language (IDL) 

234, 247 

internal application integration 36-37 

Internet Information Services (IIS) 240 

Internet Security and Acceleration Server 

2000 (ISA) 241 

intrusion detection 312 

inventory models 107 

ISO 15022 329 

Java 2 Enterprise Edition (J2EE) 148, 

233, 242, 244-253, 339 

J2EE Application Servers 233, 249-253 

Java 2 Platform, Micro Edition (J2ME) 

244 

Java 2 Platform, Standard Edition (J2SE) 

244 

Java Message Service (JMS) 229 

JNDI 214 

Just-In-Time (JIT) 433 

reporting 197 

delivery 429 


inventory model 107 

LDAP see Lightweight Directory 

Access Protocol 

legacy extension 17 

legacy systems 14-17, 97, 105 

use of software agents 403 

Lightweight Directory Access Protocol 

73 

Local Procedure Call (LPC) 242 

logistics 19, 141, 144, 328, 417, 436, 

450, 456, see e-logistics 

m-commerce see e-commerce, mobile 

3-G Networks 370 

enterprise integration issues 369 

solution providers 372-374 

market makers 446 

Index 545 

matchmaking agents 388 

Material Requirement Planning 107 

Message Authentication Codes (MACs) 

299 

message brokers 225, 255, see 

integration brokers 

message 

digest 297, 301 

passing 224 

queues 221, 224 

Message Oriented Middleware 30, 75, 

104, 215, 219-230 

messaging 141 

services 260-262 

metadata repository 58, 266 

Microsoft.NET 240, 274, 339 

Microsoft BizTalk Server Suite 274-277 

Microsoft Message Queue (MSMQ) 

228, 240 

mobile 

agents 388 

solutions 361 

MOM see Message Oriented Middleware 

Mortgage Industry Standards Maintenance 

Organization (MISMO) 183 

MQSeries 226, 251 

MRP see Material Requirement Planning 

MTS 243 

multi-agent environment 390-392 

multi-database server 60-65 

Napster 471 

negotiating agents 389 

Netfish XDI System 185, 313 

Next Generation Enterprises (NGEs) 

24, 439 

non-repudiation 35, 292, 338 

OASIS 150, 188, 204 

OBI 140 

Object Management Group — OMG 233 

ODBMS 165 

OMA — CORBA 3 233


Open Applications Group (OAG) 183 

open process-based (public process) 


Open Software Foundation 87 

Open Travel Alliance (OTA) 183 

Oracle Transparent Gateway 63-64 

order 

fulfillment 141, 448 

management 15, 19, 89, 429, 456 

management cluster 191 

Organization for the Advancement 

of Structured Information 

Standards see OASIS 

OSF see Open Software Foundation 

out-of-process server 242 

Over-The-Counter (OTC) derivatives 200 

P2P 470-485 

peer discovery 472 

peer communication 472 

P2P applications 

NextPage — NXT 3 477 

FirstPeer — Professional Servant 478 

Groove networks — Groove 1.0 478 

Gnutella 478, 484 

Applied MetaComputing — 

Legion 478 

P2P case study — Datasynapse 480 

P2P marketplaces 481-482 

P2P protocols 

Jabber 473 

JXTA 474-477 

packet filters 305 

partner and enterprise management 141 

Partner Interface Processes 150, 190-195 

PDAs 175, 364, 371 

peer 

discovery protocol 476 

endpoint protocol 476 

group 471 

information protocol 476 

membership protocol 476 

resolver protocol 476 

peer-to-peer computing see P2P 

peering portal 482 

Personal Digital Assistants see PDAs 

personalization 114, 269 

PIP clusters and segments 191 

pipe binding protocol 476 

PIPs see Partner Interface Processes 

point-to-point 223 

portal oriented integration 25, 48, 68-74 

Portal Server Framework see Portal 

Server Platform 

Portal Server Platform 70-74 

collaboration 73 

connection layer 74 

personalization 73 

presentation layer 71 

services layer 71-72 

subscription and notification 73 

portals 

horizontal 69 

vertical 69, see B2B, exchanges 

wireless 365 

process 

administration tool 140 

execution engine 139 

modeling tool 139 

reporting tool 140 

Process Paks 144 

procurement 15, 132, 141, 192, 442 

product collaboration 457 

protocol tunneling 309 

proxies 305, 307 

publish/subscribe 222 

PunchOut 203 

purchase order 203 

purchasing 442 

quality assurance 130 

reactive agents 388 

real-time information 33 

refacing see user interface integration 

Remote Access Server (RAS) 308

Remote Procedure Calls 74, 82-88, 339 

Resource Description Framework 

case study 173 

Return on Investment 20-23, 273 

RosettaNet 179, 198 

RFC 110 

RFP/RFQ bidding 446, 456 

RMI 242 

ROI 102, 285, see Return On Investment 

RosettaNet 29, 140, 144, 148, 150, 183, 

188-200, 329 

HP Supply Chain Case Study 199 

ROI 198 

RosettaNet clusters 190 

RosettaNet Dictionary (ITTD) 196 

RosettaNet implementation framework 

195 

Routers 305 

RPCs see remote procedure calls 

Sales Force Automation (SFA) 364 

scalability 

integration brokers 270 

scheduler 58 

SciQuest 

EAI case study 122 

SCM see Supply Chain Management 

Secure Sockets Layer (SSL) 158, 301, 

338 

handshake sequence 302 

security 20, 30-31, 38 

B2Bi 288-322, 311-314 


P2P 484 

Portal Server Platform 74 

strategy 291 

trends 317 

Web services 337 

wireless 356-361 

Security Services Markup Language 

(S2ML) 315 

SeeBeyond eBusiness Integration Suite 

278 

Index 547 

Service Oriented Architecture (SOA) 

326-328 

service 

broker 326 

provider 326 

requester 326 

session beans 248-249 

SGML 160-161, 354 

Short Messaging Service (SMS) 364 

Single Sign-on 312 

small and medium enterprises 153 

SOAP 121, 123, 148, 205, 251, 331, 336 

software agents 32, 385-408 

B2B 396 

autonomy 390 

characteristics 386 

information gathering 397 

mobile 394-395 

negotiation 392-393 

privacy 403 

types 387-389 

Standard Generalized Markup Language 

see SGML 

store and forward 

architecture 50 

messaging 352 

supply chain 441 

automation 21 

B2Bi-enabled 419, 422 

collaboration 419, 422-423, 436, 

448, 453, 466 

downstream activities 417 

example 413-414 

execution (SCE) 425-426 


internal activities 416 

legacy 417-419 

operational stability 430 

planning (SCP) 424, 426, 436, 466 

pull-based network 421-422 

push-based network 417, 422 

synchronization 430, 432 

upstream activities 415


Supply Chain Management 15, 19, 41, 

99, 115, 412-439, 458 

principles 420 

short lifecycle products 431 

Supplier Relationship Management 

(SRM) 467 

symmetrical encryption see encryption, 

private key 

system heterogeneity 38 

TIBCO ActiveEnterprise 116-118 

TIBCO TIB/BusinessConnect 313 

tModels 332, 335 

trading partner management 269 

transaction 

costs 33 

integrity 38, 63 

extended model 131 

longlasting B2B 131 

open nested model 131 

transaction 

oriented middleware 30, 215 

processing reference model 217 

Transaction Processing (TP) monitors 

104, 216-219, 250 

transactional integrity 


transportation management 449 

trusted third party entities 316 

TSMC 

BPM Case Study 145-147 

two-phase-commit protocol 63, 131 

UDDI 121, 123, 251, 327, 330-334, 

336, 341 

inquiry API 333 

publishers' API 333 

UN/CEFACT 204 

unified workflows 43 

Uniform Resource Identifier 167 

Universal Data Access (UDA) 240 

Universal Data Access server see multidatabase 

server 

URI see Uniform Resource Identifier 

user interface 

agents 388 


Value Added Network see VAN 

value chain 43 

role of software agents 398 

VAN 155, 183 

Vendor Managed Inventory (VMI) 433 

Virtual Private Network see VPN 

Vitria BusinessWare 143 

Voice Extensible Markup Language 

(VoXML) 380 

vortal see portals, vertical 

VPN 304, 308-310 

WAP gateway 362 

WAP Server 362 

Web services 29, 121, 268, 327-341, 

471 

framework 336 

networks 340 

Web Services 

Flow Language (WSFL) 335 

Description Language see WSDL 

WebDAV 149, 277, see Distributed 

Authoring and Versioning Protocol 

webmethods 

Juniper Networks case study 

280-283 

B2B Platform 279-283 

security 313 

Windows DNA 233, 239-244 

wireless 31-32 

workflow 133 

manager 266 

WSDL 251, 327, 333, 336 

schema 334 

wireless application architecture 350-353 

Wireless Application Protocol (WAP) 

348, 353

wireless applications 363-369, 377 

push/pull 379 

testing 382 

user-level design 381 

wireless LANs 379 

wireless Internet 347-348, see 

e-commerce, mobile 

benefits 349-350 

Wireless Markup Language see WML 

wireless network middleware 351 

wireless security 371 

first generation systems 357 

second generation systems 357 

third generation systems 358 

WAP 358-361 

Wireless Transport layer Security 

(WTLS) 359 

WML 353-354 

WMLScript 355 

X.509 standard 300 

X/Open XA model 217 

X12 179 

Index 549 

xCBL 179, 183 

XLANG 149, 275 

XML 27, 158-186, 251, 331 

and software agents 405 

databases 65-66 

DTDs 66 

elements and attributes 168 

entities 170 

message oriented ERP integration 110 

namespaces 167 

Path Language see XPath 

schemas 66, 173, 330-331 

security 314 

SOAP 121 

standards 29, 461 

XMLT 123 

XPath 149, 176 

Xpointer 176 

XSD 334 

XSL 181 

transformations 176 

processor 175

This comprehensive guide reveals the bey 

elements of successful B2B integration and 

collaborative e-commerce, by 

highlighting business needs, 

technologies, and development 

strategies. It equips companies i J 

with practical guidelines for 

quickly implementing an 

effective B2Bi strategy, and 

prepares them for the next wave 

of B2B integration and collaborative 

e-commerce. It clarifies the intricate 

dependencies among all the components of 

B2Bi, including integration patterns, enterprise 

application integration (EAI), business process 

management (BPM), Internet security, XML, 

Web services, middleware technologies, and 

integration brokers. Included are future 

technologies that will have a significant impact 

on B2Bi architectures, such as intelligent 

software agents, wireless technologies, and 

peer-to-peer computing. This reference 

provides a suitable framework for the design, 

development, and implementation of B2B 

integration, along with several case studies. 

Imperial College Press 

www.icpress.co.uk 

&5km> 

m> 


ollaborative E-commerce 

About the Author 

Gunjan Samtani is Divisional Vice 

President, Information Technology 

at UBS PaineWebber, one 

of the world's leading financial 

services firms. He has several 

years of experience in the management, 

design, architecture and 

implementation of large-scale 

enterprise and business-tobusiness 

application integration 

projects. He possesses multiple 

MS degrees in Computer Science, 

Management Information Systems 

and Computational Finance. 

P263 he 

"781860"943232"

B2B Integration : A Practical Guide to Collaborative E-commerce

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?