|
<Joe> See, Aaron, this is why our discussions don't get very far. You start out talking about RPG-CGI, and now you're complaining about being tied to the iSeries. Which side of this discussion are you going to stay on? </Joe> I was using RPG-CGI as an example. If you think that you will only ever need to talk to an iSeries, then you don't have a variety of needs as I have. For instance, I wrote an RPG application that goes out to UPS and gets Time In Transit information. I have no idea what UPS wrote their "web service" in, all I need to know is the format of the XML going in and the format coming out and the URL of where the service is located. If UPS ever changes platforms or languages it can be transparent to me because our protocol and transport is fairly generic. <Joe> Me, my ONLY business logic server will be an iSeries or its descendant running OS/400 or its descendant, with RPG talking primarily natively to a DB2 database. </Joe> Good for you. I hope that I am in that same boat down the road, but I never know. . . My corporation is primarily iSeries but has been getting into a lot of .NET lately. <Joe> You miss my point. I may not want to use web services. It's just another communication technique, and far from universally accepted at that. Just because it's the latest, doesn't mean it will last. Not long ago CORBA was the big thing, but it's gone. Jury is still out on web services. </Joe> I wasn't around for CORBA, but I am guessing that it wasn't quite as widely accepted as passing strings of text (XML) over a protocol all decent servers support (HTTP). Web services are nothing more than the next iteration of needing to get information from one machine to the next. You tout you want to use all these other protocols and that XML over HTTP is just a flash in the pan, well guess what Joe, when you started picking up your protocols there were guys saying "I just don't understand why he is using DDM (Distributed Data Management), or *SNA (System Network Architecture), why doesn't he just print it out and take it over to the other machine and hand enter it?" See my point? Sometimes I think you just like to argue un-constructively. <Joe> No, Aaron, it's not acceptable - in today's deluge of technology, it's pretty much the ONLY way to write code, at least code that stays marginally useful for more than a few months. You divide the design into layers, code them independently, and then re-implement as necessitated by business decisions. You do not design to technology, you try to keep your design technology independent and then implement the appropriate technology for business conditions. Otherwise you get stuck with outdated standards. </Joe> I didn't say don't code without layers or don't implement an interface for XML and HTTP. <Joe> For example, in case you're unaware, SOAP no longer requires HTTP or XML. The developers consciously removed that restriction in SOAP 1.2. So, one of the standards you point to so glowingly has already realized that strict adherence to the HTTP and XML is a bad idea. </Joe> Just because I was using HTTP as an example doesn't mean that I don't know you can't relay information with a variety of other popular protocols (FTP, SMTP, etc . . .) <Joe> Aaron, it's not that I don't understand the concepts. My guess is I've written more XML parsers than you've used, not to mention generators. It's just that I don't string them all into one incoherent mass of buzzwords (HTTP using XML to talk to RPG-CGI is loosely coupled!). </Joe> Joe, the only word(s) in there that could be considered "buzzwords" are "loosely coupled". I would have been just fine if you would have asked me what I meant by that but instead you chose to make Aaron sound like he writes for a hip magazine and that I use buzzwords as a red herring to redirect peoples attention so they think I know a lot. Well Joe, I openly admit that I don't know a lot. But you sure as heck are not a teacher as you claim. Be patient with the people that you think don't know as much as you. Teach us rather than trying to make yourself look better at our expense. I think it is great that you have made a lot of accomplishments, but that doesn't mean much to the rest of us if we can't get around your personality and share your knowledge. I am not saying you should pee perfume, but you don't take the role of a leader very well. I don't mean the above as an attack, but something needs to be said. Aaron Bartell -----Original Message----- From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] Sent: Wednesday, September 03, 2003 6:10 PM To: 'Web Enabling the AS400 / iSeries' Subject: RE: [WEB400] Re: Modify the IE Browser > From: Bartell, Aaron L. (TC) > > By doing the above you are tied to the iSeries platform. See, Aaron, this is why our discussions don't get very far. You start out talking about RPG-CGI, and now you're complaining about being tied to the iSeries. Which side of this discussion are you going to stay on? Me, my ONLY business logic server will be an iSeries or its descendant running OS/400 or its descendant, with RPG talking primarily natively to a DB2 database. > <Joe> > And why is an HTTP call with XML any less loosely coupled than a toolbox > call to one of the OS/400 host servers? Maybe I want to use a serial > connection. Or APPC, for security reasons. Unfortunately, you've tied > me into TCP/IP with your tightly coupled web services design. > </Joe> > > There are secure ways to transfer data with web services, try SSL over > HTTP (HTTPS). You miss my point. I may not want to use web services. It's just another communication technique, and far from universally accepted at that. Just because it's the latest, doesn't mean it will last. Not long ago CORBA was the big thing, but it's gone. Jury is still out on web services. > <Joe> > Me, I'll just put a wrapper around the delivery class and reimplement it > as needed, without having to touch my application. That's the point of > OO design. > </Joe> > > That is a perfectly acceptable way to write it, say with interfaces, but > you will have to write a new interface implementation every time a you > move that servlet to another platform and try to use it's own method of > communication. HTTP and XML are relieving the programmer from having to > know how every other platform in the world works. No, Aaron, it's not acceptable - in today's deluge of technology, it's pretty much the ONLY way to write code, at least code that stays marginally useful for more than a few months. You divide the design into layers, code them independently, and then re-implement as necessitated by business decisions. You do not design to technology, you try to keep your design technology independent and then implement the appropriate technology for business conditions. Otherwise you get stuck with outdated standards. > http://www.w3schools.com/wsdl/default.asp > http://www.w3schools.com/soap/default.asp > http://www.w3schools.com/xml/xml_http.asp Aaron, it's not that I don't understand the concepts. My guess is I've written more XML parsers than you've used, not to mention generators. It's just that I don't string them all into one incoherent mass of buzzwords (HTTP using XML to talk to RPG-CGI is loosely coupled!). For example, in case you're unaware, SOAP no longer requires HTTP or XML. The developers consciously removed that restriction in SOAP 1.2. So, one of the standards you point to so glowingly has already realized that strict adherence to the HTTP and XML is a bad idea. Seems like maybe they know something you don't... Joe _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/web400 or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.