I am trying to develop the XMPP Gateway which can send/receive from standard XMPP client. This XMPP Gateway should support conversion of XMPP request to Soap and vice-versa. Server which i am trying to integrate support only soap.
I don't want to develop XMPP Gateway from scratch. I have seen Axis Vysper but could not found how to tweak this according to my requirement.
Apache Vysper can be used to do that. Even though Vysper has no built-in support for SOAP (like the standard XMPP extension http://xmpp.org/extensions/xep-0072.html), you can create your own module to capture XMPP messages and issue SOAP calls, just like in a web app you are creating your own Servlets to intercept HTTP request and issue database calls.
One example of how to create a Module and related stuff you can find under
https://svn.apache.org/repos/asf/mina/vysper/trunk/server/core/src/test/java/org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp
Related
Is there any limitation in using a library like stanza.io for communication with an XMPP server like MongooseIM in Nativescript? What other alternatives are there?
If stanza.io supports NativeScript then there should not be any limitations.
On their GitHub main pager they say it's a Modern XMPP in the browser, with a JSON API. So it's mainly for browser env and I'm not sure about NativeScript.
As an alternative way - there is a xmpp.js lib which supports NativeScript. Their doc is a little bit shitty, but using src code there is a way to integrate successfully it.
There is a guide on how to use it for ReactNative, but you can some part from it for NativeScript, especially these part that are connected to the lib itself.
https://medium.com/#connectycube/xmpp-real-time-chat-in-react-native-8d6d5d23dd47
Also you can use some ready XMPP high level platforms for Chat, e.g. https://connectycube.com/2018/12/11/connectycube-textchat-code-sample-for-nativescript/
In this case you do not need to carte about XMPP server installation and monitoring
You will have to find a third party server or host your own one that implements XMPP protocols and connect to same using Websockets or XMPP plugin from your {N} application.
FYI, This XMPP plugin implements the same pod library explained in the MongooseIM docs, but the JavaScript apis are not fully implemented so you might have to access the native apis directly as needed.
You may also refer nativescript-xmpp-client, another exampel for XMPP implementation.
when i create a web service using eclipse 3 types of bindings appear : SOAP12BINDING,HTTPBINDING and SOAP11BINDING what do they refer to ??? am a newbie in Web services
They refer to three different ways of connecting to your web service, SOAP 1.1, SOAP 1.2 and XML over HTTP.
Clients will be able to connect to your service using any of these three protocols, and the server component will form responses with the appropriate protocol.
As far as your server component coding goes, it probably won't make a difference to you which protocol clients choose to use.
I am exploring Restlet for my next project. One of the requirements is to communicate with a legacy SOAP-based service. What is the best practice to provide RESTful style to clients, but communicate via SOAP to this back-end server?
Restlet is offering a complete HTTP client API, so even if your backend is a SOAP server, you can still communicate with it.
Although Restlet doesn't include a usual SOAP stack, you can easily use FreeMarker/Velocity templates to send SOAP messages and XPath processing to extract valuable content from answers.
I want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>
Can anyone tell me what the differences are between smack, tinder and whack?
Are tinder and whack slim-down versions of smack? Do the 3 libraries serve different purposes?
Smack is a client library. You can use it to log into an XMPP domain and make use of the functionality it provides. Typically, Smack is used to implement a instant messaging client.
Tinder is a low-level XMPP library. It provides Java implementations of basic XMPP entities, such as Stanzas (called 'Packet' in XMPP), JIDs and Components (which typically implement part of the functionality of an XMPP server). Although in theory, Tinder could be used to implement client functionality, it currently is primarily used on the server-side. Both Whack and Openfire (an XMPP server implementation) use Tinder-defined entities. Smack does not use Tinder at all.
Whack is Java library that is used to implement external components. Whack allows a Component (as defined in Tinder) to run as a stand-alone process. Whack allows you to connect this process to an XMPP domain. This way, you can extend the functionality provided by that domain without modifying the implementation of the server software.
I suggest reading this Blog entry
Introducing Tinder, an XMPP object implementation library
Smack -> Cross-platform real-time collaboration client optimized for business and organizations
Whack -> Java XMPP component library
Tinder -> Java based XMPP library, providing an implementation for XMPP stanzas and components
Tinder builds on code from Openfire and Whack. Does not replace Smack but will most likley replace Whack, OpenFire (formerly WildFire)
If you wanna create an application:
Smack will be client side Library
Whack and/or Tinder will be Server side Library