On Tue, 2 Aug 2005 11:28:49 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >Anyway, it appears that this is not really what is desired. What is >wanted is a way for the Windows program (?) to do a SOAP request to the >z/OS system and get a response back. I don't know SOAP. I cannot find >any reference to SOAP in the "z/OS: HTTP Server Planning, Installing, >and Using" manual. I'll bet it is not supported.
Supported by naked z/OS, no, not to my knowledge. It wouldn't/shouldn't be for reasons which I'll explain in a moment. >Anybody know a good reference web site for doing SOAP stuff via a Web >Server? Anybody know a __FREE__ (as in beer) z/OS Web server which will >do SOAP? Or anything else which is __FREE__ (as in beer) which can >process SOAP requests (can SOAP even require RACF authenication?) >A pointer to a "SOAP for Ignorant z/OS Sysprogs" would be nice as well. >Please remember that any solution must be __FREE__ (as in beer). Free, huh? OK, I think I can manage. But first you have to suffer through my not-so-great "SOAP for Ignorant z/OS Sysprogs" introduction. :-) SOAP stands for Simple Object Access Protocol. SOAP is one of the key standards within the Web Services family of standards. Web Services are mainly intended for application integration. They are cross-platform, language neutral, request-response interfaces for "loosely coupled" integration. Crude analogy: EDI for the masses. SOAP defines a standard XML format (a message "envelope") to make this magic happen. (There's also something called a WSDL file -- also an XML document -- which stands for Web Services Description Language. The WSDL is what you would hand a developer in order to interface with a Web Service.) SOAP has a header with various information about the service and a description of the data to exchange with the service. OK, so SOAP is the message format, WSDL is the interface descriptor, how about the delivery mechanism (or transport)? That's any standard transport: HTTP, HTTPS, MQ, and JMS are all good examples. MQ provides that high quality of service for assured delivery. HTTP is "fire and forget," and it's up to the applications at either end to handle issues like "service unavailable," timeouts, errors, etc. There are other Web Services standards such as UDDI (for registering and discovering Web Services), WS-BPEL, WS-Security, and more. Web Services are intended for application integration, so it's at least not typical for operating systems to provide Web Services interfaces all by themselves. However, there are numerous ways to develop and deploy Web Services on z/OS. Here are the "free as in beer" ones first: 1. SOAP for CICS. This option assumes you have CICS, but, if you do, it's no extra charge. SOAP for CICS ships with CICS Transaction Server 3.1. It's available as a no-charge and supported option with CICS Transaction Server 2.3 and (I believe) 2.2. It's an "as-is" (unsupported) no-charge download for CICS Transaction Server 1.3. From 2.3 forward SOAP for CICS is bidirectional. (CICS can be both a Web Services provider and consumer.) With ever CICS release the SOAP for CICS feature gets nicer and nicer. SOAP for CICS is almost free. Although you can hand code everything, it's tedious. Remember that WebSphere Developer for zSeries? Well, that's one way to get the proper tooling. SOAP is XML, and you really, really want to have a decent graphical (and automated) editor for constructing the SOAP envelopes. Really. 2. SOAP for IMS (TM). Pretty much the same thing for IMS. Look for "SOAP for IMS" at the IMS homepage (http://www.ibm.com/ims) to find it. It's no charge currently because it's "preview" (unsupported), but it'll GA before the end of 2005. In this first GA it's unidirectional (IMS as a Web Services provider only), but IBM knows that bidirectional is a requirement for some and is working on it. In both the cases above you'd need to develop a (probably relatively simple) CICS program (or IMS program) to do whatever it is you need to do for RACF. Although that scares me a little bit, so you'll want to do your due diligence on that. 3. Starting with the non-free options, WebSphere Business Integration Message Broker is a very fine way to provide Web Services interfaces to all kinds of mainframe applications. You can get a little bit of it for not much money if you're eligible for workload licensing, and for this sort of thing you probably wouldn't need much. It's more affordable on z/OS in most scenarios, actually. Typically you'd connect the Broker to mainframe applications via MQ, so you could actually Web Service-enable batch this way. 4. WebSphere Application Server also does a very fine job creating and managing Web Services. 5. There's also something called WORF which works with DB2 to make DB2 a Web Services provider and consumer. I'm not all that familiar with WORF, however, and it's probably a little far afield for what you're trying to do. Did I mention the security yellow flag here? Think about this for a moment: when you craft an easily accessible and consumable Web Services interface for creating and manipulating RACF constructs (such as IDs), how do you make sure that the Web Services interface itself is secure? That you're delegating only to competent and authorized individuals? It'd be a *really* good idea to sit down with a security architect on this one. I'm a big, big fan of being as supportive of business users as possible (and not reflexively saying "no" to everything), but you'll probably want to sit down and see if you can figure out what the underlying business need is and then figure out the "best" way to address it. Hope that helps. Timothy Sipples ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
