What makes Connectors bettter?

[jgreve]

note: Job Type actually for both Server & Parallel jobs.
note: OS Type actually for Windows & Unix.
("All Of The Above" not an option in the Job Type & OS Type lists )

So I was RTFM'ing about Connectors (excerpt below) and I started wondering why IBM claims that Connectors are better.

For example...
-- Did they rewrite the Connectors in python? Or java? *shrug* Or whatever language.
-- Are they better for only Parallel jobs (e.g. did they improve up how they work inside of orchestrate?)
-- Are they any better for Server jobs? (Apparently at least somewhat better, since IBM deprecated "Dynamic RDBMS" for Server jobs.

The searching I've done on DSXchange shows Connectors were not so stable in early DS 8.1 releases. But I haven't found anything yet that talks about why Connectors are different; what it is that makes them "better".
The docs say Connectors "offer better functionality and performance". That's swell, but how do Connectors do that? What makes them better?

I'd welcome any insight you can share.
John

----------------------------------
Documentation Excerpt from p. 5 "Connectivity Guide for DB2 Databases" (i46decd2.pdf)

--- begin excerpt---
Connectors, which offer better functionality and performance, replace some stages, which have been deprecated and removed from the palette.
...
When you create new jobs, consider using connectors instead of the deprecated stages. The following table describes which connector to use in place of which deprecated stages:

Table1. Stages and corresponding connectors
Deprecated stages
DB2Z
DB2UDBAPI
DB2UDBEnterprise
DB2UDBLoad
Connectors
DB2Connector

Deprecated stages
Dynamic RDBMS
Connectors
DB2Connector
OracleConnector
ODBCConnector

Deprecated stages
ODBCEnterprise
Connectors
ODBCConnector
etc...
--- end excerpt---

[asorrell]

Why you should use Connectors when possible:

1) They all use the same standardized interface for accessing databases. Older EE Stages were all unique in design, which made using them a pain if you weren't familiar with the particular database and its options. With the new connectors, if you learn one, you've basically learned them all.

2) For the most part, they provide equivalent or slightly better performance than the old stages. There are some kinks still being worked out that may cause specific usage patterns to be slower, so be careful in application.

3) The connectors will continue to receive upgrades to new technologies and new database revisions in the future. Deprecated stages will not be certified against new database releases, etc.

4) The Connector Migration Tool at 8.5 seems to do a fairly decent job of automating the conversion unless you are doing some really esoteric stuff in your EE stages.

I can't answer the "why" they are faster - the code is proprietary.

[eostic]

There are a few kinks that continually get worked out, but here are some other points:

a) They support Job Parameters FAR better than stages throughout all of their properties. Many properties in old stages weren't exposed in such a way that you could provide parameter values.

b) They provide stronger metadata import functions. They bring in more things (such as Views from rdbms --- they are imported AND represented as formal Views in the repository) and they handle updates to tables (deletes of columns, for example) much better.

c) They are across the suite. FT/IA/DataStage/QualityStage...


Ernie

[ray.wurlod]

IBM says they're better because someone in IBM says they're better and the sales folks pick up the cry.

Connectors make use of the Connector Access Service, which is better attuned to the architecture of Information Server. So, while there's not a whole lot of difference in DataStage alone (yet) apart from those noted, Connectors are the future, so it's a good plan to get used to them, particularly at version 8.5 and later.

[jgreve]

Thank you!
Those are some pretty good reasons that I didn't know about.
Connectors sound more robust and more productive for DataStage developers to work with.
John

[rameshrr3]

This is what a document on IBM website says ( looks like a 'radical' departure from plugin and enterprise stages when it comes to DB connectivity)

Until the advent of Connectors, DataStage (DS) relied on multiple types of stages
for database access. There were two major groups:
API (DS Server-based)
Enterprise (parallel) stages
The Connector library provides a common framework for accessing external data
sources in a reusable way across separate IS layers. The generic design of
Connectors makes them independent of the specifics of the runtime environment
in which they run.

Connectors implement a common framework that can be made use of in DS
Server and Parallel jobs, as well as Information Analyzer, FastTrack, and any
future tools, using the same runtime library.
They provide consistent user experience. They have a similar look and feel, with
minor GUI differences depending on the target type. The need for custom stage
editors is eliminated. There is a common stage editor and metadata importer with
rich capabilities.
There are a few important new concepts:
LOB support
Schema reconciliation
Formalized metadata support
The connector framework is implemented in C++. However, the same runtime
libraries can be used in J2EE applications such as Information Analyzer and
FastTrack through JNI bridging. Design-time access to connectors is done
through the Connector Access Service.
The APIs and layers are not exposed to the general public as development APIs.
They are restricted to IBM, and enable the creation of new tools and
components. One example of a component built on top of the Connector API is
the Distributed Transaction stage (DTS), which supports the execution of
distributed transactions across heterogeneous systems through the XA Protocol.


EG : For DB2 Connector
In terms of functionality, the DB2 Connector offers more capabilities than all of
the existing stages. Specifically it provides support for the following elements:
XML data type
LOBs, with data passed either inline, or by a reference mechanism. The latter
allows for LOB data of any size to be moved from a source to a target.
Client-server access to DB2 server. This overcomes a limitation with the EE
stage that can only be used in homogenous environments where DataStage
and DB2 are on identical (or the same) servers.
Options to control bulk load than EE Operator.
Design time capabilities, such as metadata import to the common model, and
enumeration of server-side information.

[rameshrr3]

for further info , This is the link to the document.

Chapter 14 deals with connectors