Re: X/Open XA Standard and Oracle
Date: Mon, 22 Nov 1993 22:30:54 GMT
Message-ID: <1993Nov22.223054.14471_at_oracle.us.oracle.com>
In article <1993Nov19.012844.2085_at_unislc.slc.unisys.com>, brandon_at_unislc.slc.unisys.com (Brandon Ausman) writes:
>
Brandon raises several interesting issues. Some of his "challenges" (Can Oracle
do that alone?) I have responded to directly. However, his points are still valid
as descriptions of options. The standard Oracle Client-Server approach and
the customary way that TP Monitors have been used represent different
architectural approaches. (I will attempt to explain more below.) Several
consequences are illustrated in the examples below. However, the real choice
is not normally one of "can Oracle alone or TP Monitors do that", but rather, "which
application architecture is "best" for this application."
> ...
> Sandor Nieuwenhuijs (snieuwen_at_nl.oracle.com) wrote:
> ...
> : 2. If you want to integrate multiple (XA-compliant) databases in one
> : transaction.
> ******
>
> ABSOLUTELY. In my humble opinion, this is the best way to use heterogenous
> databases. However, this need not only be heterogenous in one transaction
> (i.e.- transfer data from Oracle to Informix in one atomic transaction).
>
> TP monitors are useful for more than just these two, though...
>
> TP monitors give the client application writer the ability to seamlessly,
> opaquely integrate multiple databases (or other resources) into a single
> call interface. For example, you could have a service called BALANCE_INQUIRY
> which the client side could call. Based on the account number, the TP monitor
> can route that query to an Oracle DB in Houston or an Informix DB in LA. The
> application doesn't need to know where the data resides -- or in what brand
> database. The TP monitor takes care of this through data-dependent routing.
> Can Oracle do that alone??
>
Yes. You connect to an Oracle database. It, in turn, is connected by SQL*Net and a Transparent Gateway to the Informix DB in LA. The server routes the component of the transaction to the proper table. The service BALANCE_INQUIRY could be written as an Oracle stored procedure.
Not sure you can get a real, live Oracle Gateway to Informix. However the functionality is clearly already in the architecture. Alternatively, the Transparent Gateway Developer's Kit could be used to roll your own Informix transparent gateway. For queries, the server will do appropriate global query optimization. For queries with joins, the server will do all the dirty work for you, rather than asking the client to do it. Of course, the application could be developed using any Oracle or third-party development tool.
(Information source: 1993 International Oracle Users Week Proceedings, paper 229 "Oracle Open Gateway Technology, Towards one logical distributed database" by Henk Gluvers, Oracle Corportation)
> ...
>> : that you can hardly use a proper 4GL anymore, you have to go back to the
> : The big disadvantage I personally see of using a TPM is the fact
> : ages of writing zillions of lines of C or Cobol.
> ******
>
> I think you are mistaken here. You can use any 4GL which can call
> C functions/COBOL programs. Additionally, Unisys' Windows OLTP product lets
> you use DDE as a call mechanism, so you can use it from, Excel, for example.
> (This is NOT an ad, just an example of various ways to call TP monitors) I've
> also used Informix 4GL and Informix TP Toolkit to build servers. 4GLs do
> talk to TP monitors.
Both right. A screen painter/manager 4GL can do most of the forms generation work. However, you will need to write C or COBOL "glue" on the client side and Pro*C or Pro*COBOL "application servers" on the server side to convert the fuction shipped to the server to SQL, and build up the response. C is not a fully portable language. (The Oracle Product Line organization, where I work, could be as painfully aware of this as anyone in the world.)
Oracle and third-party tools can allow very rapid prototyping without any programming. Most finished applications require some PL/SQL code to control sequencing, enforce business rules, etc. One advantage of PL/SQL as a development language is that Oracle is responsible for assuming all platform portability issues. Another is that PL/SQL will be parallelized across SMP and MPP servers without additional effort on the part of the application developers (at Oracle7.1).
>
>...
>
> A few other advantages TP monitors have over a straight DB solution (not just
> Oracle...):
>
> Application Framework: With DB only solution, SQL is usually where the
> application structure comes from. SQL is (usually) only capable of
> managing local transactions or relational data. SQL, alone can't
> - Load balance application processing loads
> - Prioritize application traffic
> - Reduce network traffic through function shipping vs. data shipping
"Load balancing" is not very useful if there is only one copy of the database. SMP computer architectures already load balance using the operating system's scheduling algorithm. MPP load balancing can be done at connection time in a variety of ways. Not clear how a real application can load balance across replicated database servers. It's theoretically possible in both architectures.
Because the traffic between the client and server is implicit with the database client-server model, individual requests across the net are un-named. With the TP Monitor model, each request has a name (function, message, whatever). TP Monitors can use the names for administrative control, including prioritizing traffic, logging, tracing, etc. This functionality has to be added to a database model application using triggers and stored procedures, if desired.
The possibility of reduced network traffic might be lost if a join has to be done at the client side without the optimization and buffering available using the Oracle Server to do a distributed join, sending only the data that fully meets the where clauses out to the client.
However, what this point is really noting is that the TP Monitor style of application architecture is optimized for managing the communications bandwidth between client and server. (By contrast, the Database style of distributed application architecture is optimized to provide maximum access to and flexibility with the data.) Function-shipping focuses the design on managing the functions to be shipped, the design of the client to generate the function requests, and the application server to process the requests, returning results back to the client. The design focus is on how to partition the application for communication, hiding the details of how the data is organized. Data oriented design focuses on the data and manipulating it, hiding the details of the communications infrastructure. Neither approach is provably better, in my opinion. It is probably possible to show that anything that can be done in one model can be done in the other. The model choice should turn on what the most important task to optimize.
(Network traffic can be ruduced, in some cases, in the database model by calling stored procedures.)
>
> SQL-parsing: Many DB-only solutions submit SQL to the vendor's proprietary
> network transport, which parses and interprets the SQL, then passes
> that across the wire to the appropriate machine. Then the DB must
> parse and interpret the SQL message at the server side. This can be a
> real performance hit.
>
> TP monitors keep the precompiled SQL servers on the same machine as the
> database. The client merely calls the service with the appropriate
> data. The TPM knows where to send the request, it doesn't have to
> parse each query. This reduces the amount of traffic going over the
> wire.
>
> Application Flexibility: In a DB-only solution, you cannot take advantage of
> replicated services or data-dependent routing. Without these, you lose
> availability and flexibility.
With stored procedures and a cache of pre-parsed SQL in the server, the Oracle7 Server does not seem to be a part of the "Many DB-only solutions" above.
Replicated servers are part of the Oracle7.1 Server's functionality.
> ...
>
> TP monitors, with or without DBs, with or without XA, make nifty client/server
> application building frameworks. Much of what you would have to provide
> (network interface, routing, function calls, administration, etc.) Are already
> available via such products. Perhaps the T (transaction) in TP monitors
> should be replaced with D (distributed). (Although the transaction paradigm
> offers many features for a distributed environment -- but that's another
> discussion altogether...)
>
We agree, TP Monitors can be very useful for building some distributed clientserver solutions using the function-shipping distributed application architecture. However, for many applications it might be more appropriate to use the database distributed application architecture. It is also possible to develop some applications in each model selecting the appropriate model for the specific task. (For example, a bar code reader might be implemented using a TP monitor, while the rest of an inventory control system might work out better using database development tools.)
> Finally, with regard to 2-phase commit. Mr. Richter was partially correct in
> stating that Oracle supports 2PC with just a COMMIT statement. However,
> without a TP monitor and XA, all the participants in the transaction MUST be
> Oracle DBs. This means no other DB vendor, or e-mail system, or ATM machine,
> etc.
Using the gateways described above, the Oracle server can coordinate two-phase commits across multiple, heterogenous databases. Procedural gateways can bring in more diverse resource managers.
(source: ibid)
>
>
> --
> Brandon Ausman
> Open/OLTP (that is OnLine Transaction Processing, not Oracle basher...)
> Unisys, Salt Lake City
>
> ******
> Remember, these are _MY_ points, and _MY_ opinions, not those of Unisys Corp.
> or any of its other employees. Let me keep this much of my work. Everything
> else I turn over to the company in a polically correct manner...
>
>
Mark Johnson
UNIX System Architect
UNIX Product Line
Oracle Corporation.
These are my opinions, and, as such, are subject to change. They may or may not be shared by Oracle Corporation. Received on Mon Nov 22 1993 - 23:30:54 CET