I would like my Qt app to expose a service to another app written in .Net using WCF.
Is there any support in Qt for implementing WCF services?
AFAIK there is no 'native' Qt support for WCF or extensions; however as you know WCF can consume and expose a web service (in addition to a WCF or remoting service, etc.) All you need to do is expose it as a Web Service for the other .NET app to consume.
But that brings up an interesting aspect; usually you would write a windows service (I presume you are on Windows) which is exposed as a Web service rather than one via Qt. Qt is not ideal as it is a GUI framework (and a very good one); you will get into a few interesting situations as discussed here. It is usually easier to consume a web service with Qt as shown in this example.
Do you have the option to expose your service using some other stack such as ASP.NET or WCF or Java?
Related
I just started learning web services. In bottom up approach, I have found some examples without being deployed in any application server. I mean a standalone web service application.
Here is an example of such type.
I have also given a try and done a walk-through of deployable simple web service examples.
So far to my learning of web services, I got to know that firstly, bottom-up- approach is not recommended. Now, in bottom-up approach, this standalone web service. When is it applicable to follow standalone web service procedure?
Endpoint.publish();
I guess, this approach is provided just for beginners and not to follow as a real-time practice. Is my interpretation correct?
I would make my application as a standalone web service if it will have multiple clients like:
Web Client via a web browser
Mobile App Client
Desktop Client
Then I could build every one of them alone using whatever the technology I prefer, and make it consumes my standalone web service.
For example, You could imagine the guys behind Twitter started developing it by building their core system as web service, then they build an independent web interface application for it, then they built the Twitter Android and iPhone APP, and another one came and introduced a Twitter Desktop client like Tweetbot and TweetDeck ... etc
The Window desktop application provides C++ API that gives an array of customer information such as name and address. I want to expose this as SOAP Web Service with Security so that authorized clients (from remote servers Linux/Java based through ESB) of this web service can get this information at any time they want in SOA implementation (Java based).
The desktop application does not have a standard database. It stores its data internally. Its basically old custom built CRM application that is installed on each agent's PC box. Each agent has its own list of customers.
What are the steps to achieve this task?
Do I need to run this as Windows service?
The short answer is, yes, you can expose data from a desktop application through a SOAP web service. It is easier to do with C# and .NET, but not impossible to do from C++. What steps you need to take will depend on which platform you are developing for.
Roughly -
Implement an endpoint that supports SSL where clients can connect to your desktop application (using sockets in C++ or HTTPListener using .NET).
Write code that can receive and dispatch SOAP requests.
Handle SOAP requests and return properly formatted SOAP responses.
Handle WSDL requests.
Implement a security mechanism (cookie based or otherwise).
Using .NET, most of this is in the platform code already, you just have to put the pieces together. With C++, you may find some third party libraries but essentially you'll be writing your own.
You only need to implement a windows service if you want the data to be available while a desktop user is not logged in and running your desktop application. The challenge here is that you'll have to make sure the windows service can access the same data the desktop application is using.
Another strategy would be to access the data from your desktop application using the C++ API and Interop and implement the web service as a standard out of the box asmx hosted on IIS.
I'm investigating integrating a 3rd party web application with PeopleSoft via web services. I'm not that familiar with PeopleSoft. After some initial investigation, it appears that in order to expose any PeopleSoft functionality as web services, you have to do some considerable configuration in the Integration Broker component of the PeopleTools module. It seems that you can either define internal PeopleSoft services with "service operations" and related "handlers" or you can create a PeopleSoft service for an existing "Component Interface." Then, you have to expose that PeopleSoft service as a web service.
Are there any standard, default, out-of-the-box web services available for a PeopleSoft system, or do you always need to go through the steps of defining them in the Integration Broker?
After looking at a system like Salesforce, which has a standard web services API, it seems like there might be something similar for PeopleSoft, but I'm not finding it. Am I on the right track in thinking that the Integration Broker is the only way to go, or am I just not aware of some standard web services API that exposes basic PeopleSoft functionaity as web services?
Integration Broker (IB) is what you need to expose business logic from peoplesoft and consume it with your 3rd party tool, or to consume a webservice from your tool in peoplesoft.
There are some out of the box messages, but most of them are made to have different PIA (PeopleSoft Internet Architecture) communicate.
Be aware, IB components were almost complemently remixed in peopletools version 8.47. So it's important to give your tool's version when talking about IB.
Never heard about a standalone API for implementing web services, outside of the IB framework. IB will use dedicated class to handle sending and reception of your messages. You mention it as the handler. And if a component interface need to be used it will be done throughout this class.
Integration broker is used to setup the basic configurations that will be used in exposing and using web services. this includes making nodes and its routing available for other system to use.
http://docs.oracle.com/cd/B14099_19/integrate.1012/b14060/int_broker.htm
There are many web services available in peoplesoft. you can alsi expose any componemnt as a web services by executing very simple steps.
http://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tibr/chapter.htm?File=tibr/htm/tibr14.htm
Custom web services can also be build.
I have a C++ web service that needs to send/receive data from a Silverlight client.
Can I still use the WCF RIA client or do I need to use the sockets library directly?
Note that I'm pretty flexible on using HTTP or not, and I even prefer not to use the HTTP protocol.
Now this is just me thinking outloud here. But I'd assume that since you're using a C++ web service you're too low level to be doing anything WCF based (as WCF is usually a C# thing).
As far as using a sockets library directly, I think that a silverlight app can't do that for security reasons. Sockets are mainly for a client app that you have built yourself. But silverlight is a web client, So I would think that you'd only be left to use http requests.
Hy, I'm developing a Grails app which has to communicate with an existing Java EE application (built with EJB2).
Both the "legacy" app and the new Grails app will offer services and consume them.
For intercompatibility reasons, I'm thinking of communicating using WebServices. Now I'm wondering which frameworks I should use on both sides.
Since the Java EE application now runs under JDK5, I could use JAX-WS on I guess it would make sense to use Metro (https://jax-ws-commons.dev.java.net/grails/) on the Grails side. Does anybody have experiences with that? Or other suggestions?
If both the Grails and EJB applications live on the same LAN then there is nothing wrong with using RMI. Its the default way of talking to EJB's, is native to Java and is supported in Grails.
If you need to use Web Services then your container will have built in support for exposing the EJB's as Web Services (assuming J2EE 1.4 or later). Which container are you using?
If you cant use (or don't trust) the containers WS support then its best to pick a framework that you can use in both applications, thereby avoiding compatibility issues. Metro has worked well for me standalone but I haven't tried it with Grails.
Also there are more lightweight ways of exchanging XML messages than full SOAP'y Web Services. Hessian and Burlap are examples, plus Spring has its own HTTP messaging framework.