I am sorry for an abstract newbie question, because I am looking something like cross-language WCF.
Let's say I have an abstract service running on a server. The service implements some logic, accesses a database and exposes some interface to the client application for sending and receiving data (more a simple request-response, than a bidirectional real time, not message-based).
What are the modern and the most convenient approaches for implementing the service interface assuming the clients can be written in C++, C#, Java on Windows, Android, iOS and WEB, in other words everywhere. The service should have object-oriented interfaces in the client native languages (like WCF does in C#, for example). The network protocols can be HTTP or TCP.
As far as I see the service can be implemented on Java (with Tomcat, for example), or with Mono (using WCF, for example), but it is not clear for me, how the heterogeneous clients in different languages will consume it.
Another option is Protobuf or JSON, but as far as I see they are only a mechanism of data serialization, but not the communication with the server. So I interested in a list of the modern and widely used approaches. The key point also is the client authentication, supporting user sessions, session status, etc...
Related
I'm creating an application that consists of a web-based front-end and a c++ back-end and has the following requirements:
1) There should not be any installation of web server like Apache or similar software
2) The front-end UI should be able to trigger the back-end to perform specific measurements
3) The back-end after the computation of the measurements should return the value to the front-end in order to be depicted on the WEB UI.
I'm quite new in network programming so I made a research and I found that the absence of an installed web server can be replaced by an http server implemented in c++ with a relevant library like boost or poco.
However what confused me a lot is the way/ways that the front-end and the back-end can communicate with each other. I'm aware that C++ is able to create not only a simple but also a web socket.
What I'd like to ask is whether for the aforementioned functionality a simple socket will do the job or do I need to use web socket? If a simple socket is enough to transfer the data from the back to front-end in what way the html front-end can communicate with the c++ back-end? In your opinion which is the most stable and efficient way?
Communication with the web browser requires the use of whatever features the web browser happens to support. A "simple socket" is not something that exists in browsers.
The majority of all web applications use simple HTTP requests (so-called "AJAX") to a "REST" interface for most interactions, and WebSockets for those that require the ability to "subscribe" to live changes or where bandwidth-efficiency is more important than resilience against disconnections.
Remember that the browser only (generally) supports JavaScript, and that your communication between front-end and back-end is transactional by default (that is, request-response as opposed to message handling.)
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
I am developing an appplication that consume data from WCF Web Service, but the data need to be retrieve from differents servers applications provided by different suppliers.
The question is what programming language support the develop of a Web Services from a WSDL that already exist?
For example in .NET you could use "wsdl.exe /serverInterface" to generate a server interface. See Implementing Service Interface
In Java see: Top Down Java Bean Web Service
But I don't want the suppliers to be attached to an explicit tecnology.
... I don't want the suppliers to be attached to an explicit tecnology.
You are taking about web services. The idea with web services is that it allows interactions between heterogeneous machines (and technologies).
For the interaction to happen, there is no need for the machine to use the same programming language or technology. What's important is the protocol used. In your case SOAP.
The protocol defines the communication interface or contract. For web services, the interface is described by the Web Services Description Language (your WSDL).
WSDL is in a (more or less) human readable format, but more importantly in a machine-processable format. The idea is that you use the WSDL to generate the code/classes that respect the contract; at the server side they are called Skeletons, and at the client side, Stubs.
A lot of programming languages have means or tools to generate stubs/skeletons from WSDL but again, that's not the important part. The important part is respecting the contract.
The WSDL just allows you to automate the creation of some boilerplate code. It's not mandatory to use the WSDL to create the server/client so any technology can be used (with or without the WSDL).
As long as you do that, you do not attach yourself to an explicit technology. So in the "WCF Web Service" you mention, you can drop the "WCF" word.
The only care you must take is with the interface between the systems. You must ensure the Web Services Interoperability as we don't live in an ideal world and some specifics from the technology stack "could leak" in the contract if you are not careful.
I have a set of embedded devices that run software written in c++. The API to communicate the devices is simple: get/set/acquire parameters and signals.
I'd like to implement common web application to access all of the devices from a single point.
My idea was to add XML RPC interface to devices and then use ActiveResource to access devices from the web server. This combination doesn't seem to be used at all in practice.
I'm free to choose any protocol inside the devices. What are your recommendations?
If you're already considering XML RPC I'm assuming you have some sort of web server running on the device. I would probably choose a RESTful web service over XML RPC. If designed carefully you could have corresponding services on your Rails app.
For example:
http://somedevice/signals.json - gets all signals
http://yourrailsapp/somedevice/signals.json - gets somedevice's signals; you could use an id instead here if that makes more sense (http://yourrailsapp/devices/1/signals.json).
You probably won't find much XML RPC stuff in the Rails community. Rails itself really pushes you towards RESTful web services. Specifically a resource-oriented RESTful architecture. There are great books out there about it but it comes down to using http methods (get, put, post, delete) instead of passing parameters and then some intelligent URLS.
We have web service running for one of our projects. We want to be able to access this web service similar to how you'd access an API (such as Google Data, etc.) where you have client libraries in several languages: .NET, Java, Python, etc.
You'd be able to download these libraries (usually .DLL) from our project's website and then integrate these into your custom application.
The reason we want to have these client libraries is so that we can encrypt certain data transfers between the client and the web service and so that you wouldn't have to login a million times when you want to make a request (like you have to do when using raw SOAP requests).
So, my question is... What's the best way to do this? What would the client libraries contain, other than some encryption and a bunch of methods? What's the best way to create these libraries? Obviously some different platforms are needed to accomplish this (some flavor of Linux, maybe Mac OS), should virtual environments be used?
What are your thoughts? Thanks in advance for your help!
You would first express an API via the web service. What you are then interested in doing is creating a client "wrapper" for your web service API. This is what the client would download and use in their application (similar to Facebook.NET). This would be an assembly project and house a bunch of classes and so on. These classes would maintain the state of the program utilizing the API and would take care of all the low level plumbing work interacting with the web services by exposing a verbose object model that is easy enough for the user of your wrapper to get around in.
You could do this for any language that could interact with your web services. Java, Python, etc. I suggest using WCF though as you can use TCP for the .NET library and standard web services for the other languages. This will help you to be more performance oriented where possible.