Communication between two servers.

Post #121,946 by admin 10/20/03 9:23:06 AM Reply	Communication between two servers. On one end we have a Java web application (JSP) running in a J2EE container (actually, load balanced on 6 servers). On the other server we have a C++ daemon that performs calculation services. What I'm trying to do is figure out the best way to request services of the C++ daemon from the Java app. Ideas so far: Sockets - use a simple protocol and hold a connection open to the C++ daemon on each server. HTTP requests (not my idea) - treat the C++ app as a web service JMS, with a Java or C++ JMS client on the calculation server - block each servlet thread on a response on a JMS queue It seems to me that 1) requires more upfront work, but offers the most control. The downside is that we have to manage reconnects, failures, and so on manually. 2) has way too much overhead for each request (create/tear down a socket) but offers a nice stateless paradigm, and 3) combines the best of both, with an amount of complexity in the middle. Any other methods I'm missing, or considerations I should be aware of? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #121,964 by ChrisR 10/20/03 10:39:16 AM Reply	SOAP ...but then that's just another layer on top of http. :-)
Post #121,966 by admin 10/20/03 10:44:22 AM Reply	Right, that's what I'm trying to avoid. SOAP involves XML creation and parsing in addition to building up and tearing down a socket for each request. :-P Hey, let's use UDDI too! Then we can have dynamic discovery, XML, and HTTP layers! Oh, oh, oh... I know! Make the XML message include a serialized Java object! Serialization, discovery, XML, and HTTP! ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #121,969 by drewk 10/20/03 10:47:47 AM Reply	Welcome to my life === Implicitly condoning stupidity since 2001.
Post #122,036 by tuberculosis 10/20/03 2:13:48 PM Reply	Stupid Object Asskiss Protocol In Java, you can't escape the creepy feeling. --James Gosling
Post #122,054 by ChrisR 10/20/03 4:13:34 PM Reply	SOAP is one those decent ideas... ...that quickly got muddled - like much of XML. The MS habit of passing around stuff in binary form makes the case for readibility and loose coupling an early casualty. Might be just me, but reading SOAP calls (to & fro) gives me a headache as what is supposed to be a fairly straightforward arrangement gets really muddled in the details. As long as we're at it, why not Java RMI? Guess that's implicit within the suggestion of JNI?
Post #122,065 by ben_tilly 10/20/03 4:49:41 PM Reply	A decent idea? One of the key arguments for SOAP from the start was as a way to get around those pesky firewalls. They also admitted that security was something that SOAP did not address. Technologies which are meant to get around security solutions while not addressing security problems do not qualify as decent ideas in my book. Companies (like Microsoft) which have a history of pushing these qualify as problems. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #122,073 by ChrisR 10/20/03 5:09:00 PM Reply	Valid complaint But you still have problems with authentication if you roll your own socket scheme. And authentication is not part of JMS, though the vendors implement their own in the connection.
Post #122,090 by Arkadiy 10/20/03 7:00:33 PM Reply	In fairness, authentication and encription is supposed to be provided by the underlying layer, HTTP. MS uses SSL for encription and NT proprietary crap for authentication, HTTP's own being to weak. -- OK, George W. is deceptive to be sure. Dissembling, too. And let's not forget deceitful. He is lacking veracity and frankness, and void of sooth, though seemingly sincere in his proclivity for pretense. But he did not lie. [link\|http://www.jointhebushwhackers.com/not_a_liar.cfm\|Brian Wimer]
Post #122,088 by tuberculosis 10/20/03 6:52:00 PM Reply	No, she's a dog Actually, watching the webservices crowd define their stuff is like reliving the CORBA stuff. Next we'll need authentication, then transactions.... Mind you - I invented SOAP messaging with attachements (later polished up and claimed by MS) to solve problems with document processing submissions while at eTranslate. I still think the attachment solution was good, but the SOAP format itself is ridiculous overkill. Plus the crowd that was early adopters were every bit as pig headed as a C++ elitist in the early 90's. In Java, you can't escape the creepy feeling. --James Gosling
Post #121,970 by jb4 10/20/03 10:49:48 AM Reply	Quick alphabet soup translation: JMS? whazzat? jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #121,971 by admin 10/20/03 10:51:21 AM Reply	Java Messaging Service Like MQSeries. Point-to-point and publish-and-subscribe messaging. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,000 by jb4 10/20/03 12:00:07 PM Reply	Danke jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #121,976 by deSitter 10/20/03 10:58:24 AM Reply	roll own xinted service? Issues of authentication are then handled at a higher level. -drl
Post #121,981 by FuManChu 10/20/03 11:05:20 AM Reply	Just remember--anything manual can be automated If that's the only con to sockets (and I'm inclined that way), sounds like a winnah.
Post #121,982 by admin 10/20/03 11:09:08 AM Reply	Well, that's what I meant. As is, we will have to write the code that manages the state of the socket connection. I think there's a little bit of "web services are cool, let's use those" going on here as well... personally I don't see any advantages if you are in control of both endpoints of the connection. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,001 by tjsinclair 10/20/03 12:00:35 PM Reply	I lean towards sockets as well I haven't tried JMS but socket programming in Java is pretty straightforward. Tom Sinclair "Man, I love it when the complete absence of a plan comes together." - [link\|http://radio.weblogs.com/0104634/\|Ernie the Attorney]
Post #122,006 by admin 10/20/03 12:05:20 PM Reply	Remember there's C++ on the other end. One of the (muddled, 2nd hand) reasons for the HTTP transport was a desire to have the threads managed for us. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,027 by folkert 10/20/03 1:21:06 PM Reply	Name one: Webserver that manages Threads nicely... Solaris with Weblogic and/or Apache2 (and recent versions only) are about the only ones I can think of that work well in that respect. But given most things are not thread safe right now... IIS claims Full threading support... but only if everything is being done with the webserver machine. Apache2 does do threading, but so many thing these days are NOT multi-thread safe YET. Prolly won't be for a few years yet. Weblogic... well if you dare delv into that one... go for it. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Multi-Finethreaded Tagline ....................... ............... ..... ...........................
Post #122,033 by admin 10/20/03 2:06:56 PM Reply	I'm guessing the answer will be: IIS. Based on from whom the suggestion is coming. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #121,996 by boxley 10/20/03 11:43:09 AM Reply	4. CORBA connection but same objection as JMS Go with socket "You're just like me streak. You never left the free-fire zone.You think aspirins and meetings and cold showers are going to clean out your head. What you want is God's permission to paint the trees with the bad guys. That wont happen big mon." Clete questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #122,002 by folkert 10/20/03 12:01:46 PM Reply	My Gut reaction tells me: Even though I am on drugs right now. Sockets are the best way to go, faster, more direct and since you would be controlling both endpoints, there is literally little if any problem. Xinetd is a fine example of this mentality... except you want to re-think the data handling as it does have some restrictions of throughput. Matter of fact you could probably look at the xinetd source and get some ideas on how to handle them. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey*
Post #122,007 by admin 10/20/03 12:06:09 PM Reply	We have plenty of socket servers here already. I'm looking more for reasons not to do HTTP as well, I guess. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,012 by boxley 10/20/03 12:24:11 PM Reply	Sockets can stream, http does not, its connectionless so overhead will be higher using http and streams are faster. thanx, bill "You're just like me streak. You never left the free-fire zone.You think aspirins and meetings and cold showers are going to clean out your head. What you want is God's permission to paint the trees with the bad guys. That wont happen big mon." Clete questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #122,017 by admin 10/20/03 12:46:07 PM Reply	HTTP 1.1 supports pipelining, FYI. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,022 by folkert 10/20/03 1:12:26 PM Reply	YALOP Yet Another Layer of Processing. Okay... You could have http read the socket and send over the data over http. But why, why would you add another layer of processing. http has to be generated... gads adds tremendous complexity without any benefit of making things more robust. Complexity is nice, but only to a point. Me personally http was designed for one thing: a presentation transfer layer, it has lots of overhead and rides on top of TCP/IP. I akin this to electroncis... a transformer to be exact. A transformer is used to "isolate" or to multiply or divide (Voltage or Current). Theoretically they are supposed to be 100% efficient. In the real world, they can be as good as 98% but as bad as 50%. IOW, you lose much power just by adding a layer. The part that applies here is the Isolation. Or think of it as someone "expanding" your data, so it can travel over http. The only real help would be using an http server that compresses on the fly... of course a socket server can do that too, easier too as it doesn't have constraints placed on it by another process or service. "More work up front" usually mean "A lot less work down the road" which is usually a ++... to the good. http (specifically IIS) is a seriously moving target... if you can STOP any changes from happening... you could go that route but even Apache (or Weblogic, or WebSphere, or Roxen etc..)are still moving the specs around and break things from time to time. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* No, not here, not this time...
Post #122,026 by deSitter 10/20/03 1:19:38 PM Reply	Agreed The rexec (rsh, rlogin...) code should provide a speedy framework for setting up as complex a c/s system as you want. If all that is needed is to pull results from a calculation, you could just use r-commands in the first place. -drl
Post #122,766 by tablizer 10/24/03 11:06:10 PM Reply	Why not HTTP? I'm looking more for reasons not to do HTTP as well, I guess. What is wrong with HTTP? Anything else and you risk fire-wall problems. Server admins don't like special requests for "odd ports" at many companies. Simply use POST to send XML or comma-delimited text. ________________ oop.ismad.com
Post #122,775 by admin 10/25/03 12:19:08 AM Reply	Read the problem description. No firewalls are involved. While you are correct that firewalls preclude anything other than HTTP for the most part, this is entirely internal on our LAN. If you want to have real fun, try building a bi-directional persistent comm link between a client browser and an internal server through a firewall, when the internal server is actually a load-balanced non-clustered web farm. ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,825 by tablizer 10/25/03 5:13:44 PM Reply	You didn't qualify "too much overhead" Nothing is going to be an exact match to your desired performance or interface requirements. If you are sending streams of a gazillion little transactions, can some of them be grouped together so that packet overhead is less? Or, does each one need a reply before the next one is sent? These details are left out. ________________ oop.ismad.com
Post #122,828 by admin 10/25/03 7:36:35 PM Reply	Packet overhead doesn't matter. Computational overhead does matter. The transactions are uncoupled. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,023 by pwhysall 10/20/03 1:12:30 PM Reply	DECNet Mailboxes. Wha? You're not using VMS? Idiots, the lot of you. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #122,025 by deSitter 10/20/03 1:16:29 PM Reply	AHHH! NO!!! I had to Y2K-fix a system that was essentially a DECNet roll-your-own C/S system, written in - no kidding - DEC BASIC. AAAHHHH! AAAAHHHHHHH! -drl
Post #122,029 by pwhysall 10/20/03 1:23:32 PM Reply	Silence, heretic. The guards will be with you presently. Your stake is ready. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #122,040 by tuberculosis 10/20/03 2:25:08 PM Reply	Socket to me Does the C++ thing need to be a daemon? Why? Is there something in the C++ thing that shares data or can you have one instance per invocation? Would melding it into the appserver via JNI be evil? >Sockets - use a simple protocol and hold a connection open to the C++ daemon on each server. Nice, simple. You'll want to pool the connections of course. >HTTP requests (not my idea) - treat the C++ app as a web service Sockets with crap in front. I don't see the advantage. Plus, if the C++ code is memory resident and stateful (why else is it a daemon?), you still have to deal with the same threading issues with the sockets. >JMS, with a Java or C++ JMS client on the calculation server - block each servlet thread on a response on a JMS queue If you need synchronous responses, then this is a waste of machinery I think. Although its probably less crappy than HTTP. Not sure about the quality of C++ JMS client code available. Given your org's experience with sockets already - I'd go with those as they are "The Simplest Thing That Could Possibly Work (TM)" In Java, you can't escape the creepy feeling. --James Gosling
Post #122,047 by admin 10/20/03 2:56:20 PM Reply	Why the daemon: The code needs to be very, very fast, and the trade-off is memory for speed. The daemon can take up to 10 minutes to load all of the data necessary to make the calculations. The datafeed is very high volume and the calculations are non-trivial. One of those few applications that really does need to be extremely efficient. I'm supposing here, but I think the HTTP connection really means "OCX/ActiveX/whateverXitistoday used as a web service in IIS and .NET". I don't have all the details, however; the information was second hand. This is just a suspicion. Many of the same disadvantages apply if it's "C++ through JNI in a Java web service". WRT your question about JNI, that was one of the alternatives I had thought of. If we're wrapping the C++ stuff in a framework, why not use a Java appserver as the framework so it can run on more than just Windows. WRT synchronous responses and JMS, one advantage is that one or both ends can go down and the messages are saved. We get that for free. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,070 by FuManChu 10/20/03 5:03:37 PM Reply	Not an answer then, but a plan of attack :) Taking up the mantra: "design first, then optimize" 1. I'm supposing here, but I think the HTTP connection really means "OCX/ActiveX/whateverXitistoday used as a web service in IIS and .NET". Get them to spell this out in a design meeting. 2. Suggest that this decision be left for later, when several competing strategies can be tested. Abstract the communication process. 3. When it comes time to finalize the comms, remind them: The code needs to be very, very fast, and the trade-off is memory for speed...One of those few applications that really does need to be extremely efficient. 4. Show the native socket app blowing .NET out of the water. 5. Reintegrate the abstracted comms code for a final speed improvement. Ooh, I can work this Team Thinking, can't I? >:) "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
Post #122,072 by admin 10/20/03 5:05:20 PM Reply	Complicated political situation. That might work, given different personalities. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,089 by tuberculosis 10/20/03 6:56:01 PM Reply	You mean you're not king? Dude, just lay down the law. Surely the other hacks will bow down before the admin-guy? In Java, you can't escape the creepy feeling. --James Gosling
Post #122,050 by gdaustin 10/20/03 3:10:50 PM 10/20/03 3:11:19 PM Reply	Tuxedo/Java Jolt? If you have the money, you might look at Tuxedo and Java Jolt. Tuxedo allows you to provide C++ code in the form of services, and Jolt allows you to create your Tuxedo output as a Java class, instead of having to parse through a buffer. Again, it will cost some money, but it performs well, and it's tried and true reliable. Edited by gdaustin Oct. 20, 2003, 03:11:19 PM EDT Expand All History

Welcome to IWETHEY!