TPF Users Group Task Force

Application Access Alternatives10/14/2002

2Confidential / All Rights Reserved

Background

Much discussion over the last three TPF User

Group Conferences over the role TPF can or

should play in more modern access methods

Task Force was formed to see if there was a

common set of requirements which could be

developed and submitted to IBM

3Confidential / All Rights Reserved

First, Let’s Understand The Scope

TPF plays different roles at different companies but

generally supports three types of messaging: Community Access Methods

These offerings provide connectivity to end-users of TPF

services and offerings

Internal Messaging These allow information to be exchanged between different

platforms within a company’s systems

Supplier/Provider Messaging These offerings provide connectivity to business partners,

suppliers and providers

4Confidential / All Rights Reserved

Varying Characteristics

Each of these communities has different characteristics

(particularly with the age and type of systems they use)

Ability to influence or change the connectivity also varies

depending on the nature and importance to the business Community Access Methods - Some ability to influence but must

encourage rather than dictate

Internal Messaging - Complete control over how and what is

exchanged within it’s domain

Supplier/Provider Messaging - Limited ability to influence and

must adopt and conform to supplier/provider connectivity

requirements (Companies can influence and encourage but

ultimately control rests with the supplier/provider)

5Confidential / All Rights Reserved

Collapsing around a few standards

The messaging landscape has started to collapse

around some basic structures/frameworks which

will start to permeate each of the categories XML is rapidly evolving as industry preferred means of

formatting messaging payloads

Web Services, .Net and J2EE all leverage XML as the

payload and then wrap more sophisticated headers

around the payload

Scope, then, is to provide forward migration from

current messaging support to the new messaging

frameworks in a timely, strategic manner

6Confidential / All Rights Reserved

How to handle?

This is complicated by the different things we have all done to keep our systems current so there won’t be a single way to move forward A lot of “screen scrapers” have developed as integration

engines and database abstractors (e.g. Java Data Objects) and do some of this already

TPF plays different roles for each of us

We do have some existing IBM infrastructure already, though, in the works and in production INETD and superior TCP/IP features (thanks to Mark

Gambino and team)

XML parser

7Confidential / All Rights Reserved

Proposal - Concentrate on Foundations

Key principles IP as the foundation for new connectivity

Native Stack/CLAW for TPF

Standardized TCP/IP access for all other environments

Converge on XML Leverage existing protocols and accesses?

Extend existing structured data?

TPF based aggregation utilities?

Communications/Messaging utilities in or near TPF Handle .NET, SOAP and J2EE headers?

Billing/logging for new message types?

Service based activation tables (similar to action code tables)?

8Confidential / All Rights Reserved

Possible Requirements?

More robust XML parsers and tools

XML schema repositories on TPF

Standard library of common routines (e.g. ASCII to

EBCDIC)

Service based activation tables

Naming services and/or interfaces (e.g. UDDI,

WSDL) LDAP on TPF?