![[ZOIS]](pics/little.zois.gif){kind=small}
Home Page *
Contact ZOIS *
Search *
Table of Contents *
Open OLTP News
These are raw answers and ongoing discussions between Mr. OLTP and
correspondents on OLTP and other matters that have arisen from viewing
the ZOIS site.
So far there's been queries/discussions on ...
29th August 1998
Jamie from London asks ...
I am being asked to configure firewall filtering to port level for access to a Tuxedo TP.
I have been told that Tuxedo will only allow a single connection to each TCP port, and subsequently am having to open up large ranges of ports on my firewall to accommodate multiple clients. Is this a standard feature of Tuxedo, or is the system user configurable to specify either single or multiple connections per port?
Also, the Tuxedo server we are running expects call to be established on a specific port in the 8000 range, but then responds to connections with a source port on the 2000 range (again, one port per connection). Is this port transposition standard or can it be overridden in the config?
Thanks for your help.
This is a function of the architecture you are using, but also, possibly a misinterpretation of how TCP protocols work and how one can Firewall TCP oriented sites.
It sounds like you are using /WS. /WS is a proxy client mechanism which allows the Tuxedo API to migrated to simpler platforms. Traditionally the proxy for /WS could be concentrated, say, on an office server, which then could participate in a bulletin board with a database server centrally. More recently /Domain has been used to accomplish the same task a little more scalably. This hierarchy of TCP connects was designed to reduce resource usage in large systems. Each TCP connection absorbs a small but finite amount of the machines resource which can impact the system when you have large numbers of essentially inactive connections. The hierarchical arrangement is designed to funnel this traffic into a small number of TCP connections which would be handling large numbers of messages from large numbers of terminals.
The second part of this rather depends upon your Firewall. TCP connections are made using ports, a sometimes named 16 bit number. A fully established connection uses two ports one for the source and one for the destination. The destination port is the one that you assign, and the source port will be chosen by the TCP/IP system. A TCP connection is impossible with out both ports so your Firewall policy should be to limit conversations to a TCP conversation with a specific destination port.
As they say, the devil is in the detail. The detail is probably best supplied by folks more familiar with your system than I.
Update: After some further correspondence with others (sadly not the original author) it seems that some things need more explanation.
Tuxedo uses a mechanism to connect clients using two processes (one called the Workstation Listener (WSL) and the other the Workstation Handler (WSH). When a WSL receives a connection request from a workstation (on a known port) it hands the connection over to a WSH. The WSH then makes a reverse connection to the client. There is therefore a need to provide firewall holes for both the inbound connection to WSL but also the outbound WSH connections as well.
Firewall administrators usually find the WSH connection vexing,
as it means opening ports above 2048 to outbound connections. In later
Tuxedos (starting with 6.5) two new options have been added to the WSL
command line, -p and -P. They serve to limit
(between a minimum and a maximum, respectively) the range of outbound
ports the WSH will use.
If your firewall administrators still find this confusing you can remind them that a similar mechanism exists in "FTP's active connection". If they claim ignorance of that, then for a small fee ...
28th November 1998
Robert from Greenwood asks ...
Are there any descendents of the Coward or Slack Family's of Cockermouth still living in the area? My Grandfather was Thomas Slack Coward born March 23, 1891 in Cockermouth. He was the son of John Coward of Lorton Road, born April 1, 1851, died March 29, 1898 and was interred in Cockermouth Cemetery. His mother was Mary Slack Bowman Coward (Bowman was a previous marriage) born October 12, 1855, died January 14, 1938 and was also interred in Cockermouth Cemetery. I think there is some type of monument in Cockermouth for John Coward.(Maybe in the Cemetery) Mary Slack Coward resided at Trough House Dovenby Cockermouth at the time of her death. John and Mary had four sons Anthony, Thomas, Henry and Herbert. Mary also had a daughter Hannah Blanche Bowman Poole from her previous marriage to a Mr. Bowman. Sincerely, Robert.
Thanks for your interest in our web site.
Unfortunately we have neither a Coward or a Slack working here. I, personally know of nobody of that name in Cockermouth. Looking at the 'phone book I note no Cowards actually in Cockermouth, but about 20 or so in Cumbria as a whole, and there's a similar result for Slack. There's no monument that I can recall in Cockermouth (I assume that's Lorton Road) Cemetery to either a Slack or a Coward (but then again I've never really looked).
Your best bet is possibly a letter to the West Cumberland Times and Star, the local weekly paper for this area. There are, occasionally, letters of your type published so I would expect that your's may be of interest. The address given is "Reader's Viewpoints, West Cumberland Times and Star, 23 Oxford Street, Workington CA14 2AN". They add ...
"Please be as brief as possible. All correspondence must be signed by the author and contain an address and day-time telephone number.
"The Editor reserves the right to amend letters for reasons of length or legality."
Regards, Martin Sullivan (Webmaster at ZOIS Ltd.).
28th November 1998
Jim from New York asks ...
I've heard of a standard that will allow TPM vendors to interoperate (coordinate within same transaction across vendors). Can you tell me more about this standard and its status?
There is such a de jure standard, part of the ISO presentation layer, known as XAP (pronounced `Zap'). This spawn of Subcommittee 21 has probably got an ISO number by now, but I can't remember it off-hand. What is more important is the uptake amongst TPM vendors, which is, one could say, patchy to say the least. Of the the TPM that we hold dear only Tuxedo, to my certain knowledge will interoperate with it. It has, however, I remember, been used in interoperability work with some proprietary and non-IBM mainframe TPM, so this is the way to go if you've got, say Fujitsu-ICL Mainframes and want to co-ordinate with, oh, say Unisys.
The de facto standard is, as so often the case, to pretend to be the market leader and this means as far as TPM are concerned CICS. So SNA, PU2.1, LU6.2 and all that murky magic.
Microsoft, Tandem, Compaq &al. are promulgating a new Web oriented standard, which is going through the IETF route and is currently at draft. Microsoft have said specifically that they will not support the current ISO standard and IBM/Transarc have quietly ignored it.
There have been a number of IETF efforts before, in this area, going forward to fully fledged RFC but I've never seen anything in the field.
The whole question of TPM interoperability is an intriguing one. Usually companies have but two or three TPM and gateways can written or acquired to give ad-hoc solutions. Thereby, it has to be said, generating business for the likes of us.
It is refreshing not to have a question about the genealogy of ZOIS and/or the town in which we are based. This will become the basis of a Mr. OLTP answer (with links and references) and you will be credited as Jim from New York (I guess).
Regards, Martin.
29th November 1998
Jim from New York asks ...
Many vendors integrate the TX/XA component with their overall middleware offering. I would like to buy a best-of-breed DTS-only component. For example, OTS from Iona (Transarcs OTS library). Do others exist?
Both XA and TX are simply interfaces. Both are used in Transaction demarcation and I've touched on XA in Mr. OLTP's answers. XA is the interface between a TPM and a database manager capable of doing a two phased commit (known in TPM jargon as a Resource Manager, or RM for short. You don't really need to concern your self with XA unless you are writing a new interface for a new RM or TPM. The standard is from X/Open and widely supported and used.
TX on the other hand is a X/Open standard which allows Transaction demarcation in user programs. It too is widely supported by TPM, but only Top End suggests that you make wide scale use of it. Other TPM on Open Systems do have the interface but would have you use their proprietary interfaces which, it has to be said, have a greater scope in Distributed TPM where more than one Transaction Program will be involved in the Transaction. CICS on Open Systems follows its Mainframe cousin and doesn't offer TX at all.
You need a TPM to get from TX to XA, for there are other things involved as well. A TPM, as far as Transaction Management is concerned is quite a complicated beast. It has to maintain state in a robust recoverable way, so that if there's a system crash nothing is lost. It also has to do this with a large number of possibly concurrent Transactions per unit time. TPM also as a core product offer a way of connect a large number of clients to a database or databases and make it easy to scale work with these databases. Then you get all the other gubbins which may or may not be relevant to you and your business.
OTS is yet another standard, which I've not yet produced a paper on for the site, it's in the list of vapour though! (see Site News). Part of the more recent CORBA standard it allows an object oriented interface to Transactions, or if you prefer an ORB to behave in a standard and recoverable way. Encina has an OTS interface (perpetually in Beta) and this is bundled with Orbix's ORB and may be called Orbix OTS, when you get the lot from Iona. Check out the newly announced M3 from BEA and to complete the picture IBM have Component Broker, an ORB and OTS Transaction Manager bundle. Then there's Enterprise Java Beans and a Java Transaction Service, JTS. So lots going on there.
Hum, again the possibility of a couple of Mr. OLTP answers there, possibly an enlarged response to "What is XA?" as well as one on "What is OTS?". I'll mail you when they get published.
Oh, and what do I think is best? It's the stock weedy answer again, I'm afraid.
Regards, Martin.
30th November 1998
Martin, thanks for the background. I was a senior consultant with BEA and have worked with M3, Tuxedo, Encina and Iona OTS.
My specific question is whether there is a vendor that sells a transaction monitoring only solution. The tx component would provide the following:
The problem that I see is that each vendor wraps the knowledge that a request is involved in a current transaction (and the GTRID) into its own internal messaging buffer to send between processes and machines. A receiving process will see this and will involve itself in the transaction. All of this detection and involvement appears to be within each vendor's proprietary message format and linked-libraries.
So I think that - as of today - there is no independent transaction monitoring component (that handles only the xa_open()/prepare/commit and logging and inter-resource communications)? Is this correct?
Perhaps OMG's GIOP protocol gives hope of inter-TPM cooperation (I hear there is an evolving standard for inter-TPM coop?).
Thanks again, Jim.
Sorry about the delay in getting back to you Jim, I've been snowed under with both work and family stuff over the holiday break (I'm now a father for the second time).
To my knowledge, you are right, the Transactional information that flows between TPM can be considered proprietary. All the players in the field though would claim that there solution is the open, standard one, if only everybody else would adopt it. As examples, Top End had something called TX+ which it used to communicate between Nodes and promoted as a standard and Encina uses standard DCE RPCs which it makes Transactional. The most vendor neutral effort was promulgated by the OSI, but apart from some non-IBM Mainframe folk it only could be found in Tuxedo. There's a very good review paper on this by Graham Chan, "DTP_STANDARDS".
Most of the active work is, as you've observed, all going on in the CORBA and OTS arena. It has to be noted, however, that Microsoft have said that they will not support the OSI standard and are very quiet about OTS. So, you never know, more of the same, only this time object oriented.
I should point out that in addition to the client of one TPM in the server of another approach, there's also IBM's MQ as an intermediary which can be driven by a number of TPM (for full two phased commit) and is distributed on a large number of platforms. While I'm dropping product names, I've worked with Garth Eaglesfield, who you may know, on design issues like this for a Client with both Tuxedo and ACMSxp. I think the server as client of another was the favoured approach there.
Regards, Martin.
Larry from Internet-land asks ...
So sorry to take up your time. I have been asked to put together a matrix of OLTP middleware listing the summary of features and what the pricing looks like. I am at a loss!
Could you help in any way?
I've thought about this and thought it might be a nice addition to the web site. Then the enormity of it came to me (since none of the four TPM are particularly simple and the term middleware covers a host of products, not just TPM).
Pricing is an interesting one. Unfortunately TPM are not priced up front (or rarely) and as a result the final price that you'll pay is found after protracted negotiation, may include other software from the same source and (in the case of IBM) can include hardware too. The price is usually based on the number of seats and the size of development. One thing I can say is they aren't cheap, so you don't buy them unless you need them.
Wayne from Boston asks ...
I'm debating whether to use MQ Series or Tuxedo. I think both offer the same transactional integrity (guaranteed delivery, security, etc), however, Tuxedo is very expensive compared to MQ. I have a back office system that runs on a Tandem so both are good fits for what I need to accomplish. Someone told me if I don't need two-phased commits then I should use MQ. What are your thoughts?
MQ Series is primarily a Reliable Queue with a messaging capability. It guarantees that the message will stay in stable storage or be delivered. It operates with a one phased commit. If two phase commit is required to coordinate with another database then a TPM is required and MQ supports the XA interface.
Tuxedo is a TPM and does have a reliable queue bundled with it (in-fact all TPM of my acquaintance do). Tuxedo's is called /Q. Of course if you later decided to have 2PC you don't have to buy a TPM.
So, if your not after 2PC and just want the message delivery part and don't have zillions of clients wanting to do the same thing, then MQ looks best.
See, Mr. OLTP won't recommend a TPM for everything!
A Company that Shall Remain Nameless asks ...
Nameless Company is carrying out an independent analysis of the satisfaction with tools for Web site visitors tracking and measurement of advertising results.
... and then a sort of sales pitch for their stuff.
Thank you for your interest in our site. Although it can be considered a great big ad. for ZOIS's not inconsiderable OLTP skills, we do not actually advertise products or services on it and do not track visitors (other than the occasional glance at the logs to see what pages are popular).
22th August 2000
Moira and John from somewhere in Australia ask ...
We have just found out that my husband's Great Grand father was from Cockermouth and lived in Kirkgate. Can you tell us if Kirkgate is still there?
Kirkgate is largely a residential street with a
number of businesses in it. These include two churches, an arts centre/cinema,
a cafe, two pubs and two
dental surgeries. Operating from their houses one finds an On-Line Transaction Processing (OLTP)
Consultant, a Roofer and a Undertaker amongst others. There are also a
number of houses (about 6) which appear to be holiday lets. You'll find
more using Google (which I can recommend). Finally, there's
a picture of Kirkgate on Instinct Training's Cockermouth
page.
$Date: 2008/08/03 13:14:45 $