Re: SOAP, WSIT, I'm LOST, sort of...

Doug Phillips wrote:
On Sep 7, 9:43 am, Jan-Erik Söderholm <jan-erik.soderh...@xxxxxxxxx>
wrote:
Jeffrey H. Coffield wrote:
Jan-Erik Söderholm wrote:
To add the the picture, this "new" interface is ment
to complement the current that is a simple mail based
communication. The "other side" simply sends a mail
to a specific user, using an agreed on subject with a
datafile ZIP'ed and attachede using standrad MIME format.
On the VMS system ("my" system) this mail is taken care
of using DELIVER/MPACK/MUNPACK/UNZIP and the datafile
is finely FTP'ed over to an IBM mainframe to be stored
into a central DB2 database. The mainframe interface is
not the target right now.
Now, some users would like to have an alternative to
this mail based communication. FTP has been discussed.
WEB Services was also mentioned. And that's why I was
asking.
OK, I have to dig a little more into this.
As you said, one of the problems with open source
stuff is that it might be hard to find a consistant
set of documentation...
Jan-Erik.
If the "other side" is a person, why not put up a web page with a file
upload? If the "other side" is a program, then some change would have to
be made since it currently sends a e-mail. That can usually be switched
to cURL to do the post. The web page on your side is the same.
Jeff Coffield
No, the other side are different client application. And they'd
like to use the latest busniess buzz-words, of course. Whatever
that looks good in the data sheets. :-) And it should be a fully
automated setup. No manual intervention in any part.

So, the *BEST* solution for *me*, is one where the client can use
WEB services (or whatever "new" tools they like) and I can
continue with the same hardware/VMS/OSU setup.

I do not now what tools there are on Windows servers, but WEB Services
was mentioned as one that they'd look at as interesting.

Now, I guess I need some XML tool to receive and decode whetever
the WEB Servicesa/SOAP tools at the client creates, right ?

Jan-Erik.

Because your application has a limited/specialized need, and because
XML is just text, it's simple to parse it yourself and extract
whatever you need without implementing the entire XML "standard." You
could even do it in DCL if you wanted (but that would not be my first
choice.)

And, you could tell the client that you're using SOAP (but not tell
him that stands for Same Old Application Program;-)


OK.
So the clients "SOAP-call" could point to some URL mapped
in the OSU server to a DCL script (just as usual) that then
does the usual HTML/XML decoding. Maybe calling a small C/perl
or whatever hack to speed it up. Hm, have to look closer at that.
So the client can use any SAOP tool of his selection, on my
side it's just a specialy formatted html/xml file, right ?

Jan-Erik.
.