Assume I have simple program (executable compiled from a C program)that provides text information running as Windows XP service. AFAIK Windows service can communicate with any external process running on the same PC but not with remote processes. How can I convert this windows service to SOAP Web service so that it responds to any any SOAP requests from any remote host?
What are the steps for this like what library to use (not .NET) ?
There's no magic library that will do it for you, you have to create a Program yourself and expose a SOAP endpoint with the service functionality.
Windows processes can communicate with other processes if those process offer a way for that communication to happen (inter-process messaging, reading system event queues, etc), so assuming your C program do offers a way for that communication to happen, your new program can feed that program the input, get the text information and return it to the client consuming your web service.
If you don't want to use .NET maybe you can use some other high level language like Java, Ruby or Python than can help you get your service up un running faster, but you have to create a program yourself, there's no magic library to wrap a program in and make it a SOAP web service.
Related
My application it's C++ service. And I need to add API for it. I consider that it will be XML/JSON RPC based API. How should I design a program for reusing existing code base and provide API.
I see following options:
My application will work via RPC layer. Seems that it's bad option due to low performance;
Before starting of service I will fork it and run my application in the first process and RPC server in the second; Seems ok, but how to restart RPC server in this case?
I guess there is a well known pattern for such issues.
Thanks.
If you can use a web server, then the FastCGI concept might be what you're looking for. One of the main duties of FastCGI is to allow you to put on a public API (from the web server) that internally calls the "real" application, in your case the resident C++ service. So all work is done at the web server to create the public API using any technology you wish, and little or no code changes done in your C++ service.
I have a WCF service that uses duplex contracts via a netTCP binding. It's basically a chat server that relays the messages it receives to the connected clients. The service, and the C# client work great.
What I want to do is create an unmanaged C++ client for the service. Is this possible? And if so, how is this achieved?
I'm ok with using 3rd party libraries, just no .Net
use the little-known WWS - Windows Web Services. This is basically WCF but native code. Its much smaller in size and much faster - MSDN magazine shows some benchmarks (yeah, ok) that say WWS handling SOAP is faster than WCF's Net.TCP. WWS net.tcp calls are several times faster than WCF :)
WWS also runs with a much reduced working set, 500kb vs 4.5mb for the simplest of simple services.
That link has sample code for you.
I think you get this library for free in Windows 7. You can get it for XP as a separate download.
I have written a windows service and I want to communicate(IPC) it with a win32 application(Desktop), can anyone tell me what should I exactly do for making this communication. In my case my Service is server and other process is client. Process should establish connection with the service whenever a user launches it on his machine.
I have written services which support named pipes like you describe. I do not have to do anything special to set permissions for the client to open & read/write the named pipe. I found the following Microsoft articles useful when developing my code:
"The Complete Service Sample":
http://msdn2.microsoft.com/en-us/library/bb540476(VS.85).aspx
"Named Pipe Server Using Completion Routines" :
http://msdn.microsoft.com/en-us/library/aa365601(VS.85).aspx
Following is a list of options for inter-process communication on Windows:
1. Component Object Model (COM)
2. Remote Procedure Call (RPC)
3. Windows Sockets
You can set service type as Automatic, mean it will start once the machine up& running
Please refer.
https://www.codeguru.com/cpp/w-p/system/sharedmemory/article.php/c2879/Shared-Memory-Inter-Process-Communication-IPC.htm
We have to communicate with a C++ component from a Java EE web application and my proposal involved using JMS server to communicate with the C++ component which is located on other machine.
However the developer of the C++ component wants me to open up TCP/IP sockets from the webapplication and communicate over XML. My view is that socket programming in web application is error prone and will not scale well since there is a limited amount of sockets that can be opened up.
Please let me have your architecture/design preference on using JMS vs TCP/IP sockets.
Thank you
Of course it's case by case. But give HTTP a serious chance. It is a good way to cross platform boundaries. It gives you ways to swap out the backend easily and there are many ways to scale it. I've used it from various platforms to hit centralized authentication service written in modern language. I've also done the opposite by putting frontend to a legacy code by turning it into a web server.
The best part about HTTP is that it's a standard protocol, so almost any platform is able to serve it and consume it out of the box. HTTP(S) or TCP takes care of many of the issues like reliability and security.
We have some COBOL programs in our financial applications which need to interact with some of our backend systems. One of the available interfaces is through a web service. Can a program written in Cobol make requests to a web service?
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
I've never used COBOL but from quick Google search it looks like it's possible.
This looks like it'll help, and talks about integrating webservices with cobol through c code.
What platform is this on? IBM's CICS supports webservices invokationnn from cobol program via EXEC CICS INVOKE.
ibm is now trying to implement a technology called embedded websphere with java.
ibm belives this is the only way to give the life to mainframes.
I know I can write a WebService with Delphi and call a COBOL DLL or
call a Delphi dll to comunicate with webservice.
Right now Im writing a webservice client, it will be a DLL, and Ill call from old COBOL systems.
If you have and are using CICS, it has built-in mechanisms for that. But assuming you can't use that for some reason, you can build an HTTP client using the IBM TCP/IP 'EZASOKET' modules.
I work for a company with a z/OS system running mostly COBOL, batch (JCL) and CICS. To call webservices, we wrote a module to implement HTTP 1.0 using TCP/IP. With modules
EZASOKET
GETHOSTBYNAME
SOCKET
CONNECT
WRITE
FCNTL
READ
CLOSE
SELECTEX
supplementary modules:
EZACIC04 translates EBCDIC to ASCII
EZACIC05 translates ASCII to EBCDIC
EZACIC06 convert character to bit mask
EZACIC08 decode IP address
Since I wrote this for my company, I can't just give out the code. But for reference, it took me 3 days to write the module (plus a little debugging later), and that was with an example to start with that did a partial hacky way of doing it.
You will need to read through IBM's references to know how to use the EZA modules.
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.halc001/sampcs.htm