I want to know the difference between Sip Servlet and JAIN-SIP.
From the stack overflow question's answer, here . I cannot understand the difference between sip servlet and JAIN-SIP. I want to know what is the purpose of JAIN-SIP specification when both sip servlet and JAIN-SIP specification has to create SIP application.
Please also guide me; I want to develop a mobile(android) application in which I want video chat and also conference call functionality. Is this can be done by using JAIN-SIP? (Guide me on this) Please... Thank you
JAIN-SIP is a low-level light-weight SIP stack API while Sip Servlets extends HTTP Servlets and has other dependencies. In general you have more freedom and fine-grained APIs with JAIN-SIP and you can integrate it anywhere. Sip Servlets is a simplified API like HTTP servlets and usually comes with its own integrated environment, a Java EE container or HTTP servlet container.
In terms of flexibility Sip Servlets has some restrictions on which headers you are allowed to touch. You can't stamp your own data into tags, branch ids or IPs for example. Sip Servlets also usually don't allow for more stateless designs. Sip Servlets is best suited for a stateful server, UAS or B2BUA apps with enterprise logic, but it can work in other roles too.
For an android client app JAIN-SIP is the best choice no doubt about it. On the server side, it depends on the specifics of the application.
Related
I like the APIs of the Retrofit and OkHttp rest/http libraries from Square. I am evaluating options for writing a server-side rest client. For each request to my SOAP-based web service, I have to consume another, restful web service, thus my need for a rest client.
My question is, are Retrofit and OkHttp suitable for server-side use in a highly concurrent web app, or are there likely to be issues, known or otherwise, stemming from these APIs having been designed for use primarily outside of the server-side?
Reading the documentation and perusing the code, nothing jumped out at me to indicate that these libraries would not be suitable. But I don't want to be a guinea pig either. Has anyone experienced any issues with server-side use under high load/concurrency? Had success? Anyone from the dev teams for those libraries care to comment? ;)
We use OkHttp on the Square Cash server and we haven't had problems.
Some of the default settings are not suitable for server side usage, for example, the maximum number of concurrent requests per host defaults to 5.
There is some discussion on this at https://github.com/square/okhttp/issues/4354.
In the microservices architecture world (using Spring Framework), Retrofit/Okhttp may not be a good fit as a REST client for inter-service communication. Using WebClient/RestTemplate will have at least the below advantages over using retrofit for the same purpose:
RestTemplate/WebClient can be easily configured to make use of client-side load balancing (Ribbon), thereby requests can be rotated among various instances or another microservice.
Hystrix can be easily configured with RestTemplate, thereby increasing the fault tolerance (circuit breaker pattern) of the overall system w.r.t inter-service communication.
Service discovery can be easily configured using Eureka or Consul, thereby the client need not know the host/port/protocol of the target web service. All we need is to enable the discovery client.
Alternatively, you can also explore Feign, which is a declarative web service client similar to retrofit, but with all the advantages of RestTemplate.
You can also have a loot at the following article:
https://www.javacodemonk.com/retrofit-vs-feignclient-on-server-side-with-spring-cloud-d7f199c4
I have an architectural question. I want a Java client to communicate with a Java EE server (Glassfish). I don't want to use remote EJB invocations and use GlassFish Application Client Container, I need something more lightweight. So I consider calls over HTTP.
RESTful seems to me the easiest way from the technical point of view. But I'm confused about architectural style. I mean, I'm NOT creating a system that is defined in terms of 'resources', but in terms of 'methods'. So JAX-WS may be appropriate, but I would prefer to transfer not only XML, but just raw data in HTTP message body.
Should I consider servlets or something else? What is the best practices for client-server communication?
raw data in http message body
What kind of raw data, like bytes encoded in base64? That doesn't really sound like the typical job for HTTP. Somewhere in between EJB and Webservices there are other solutions that may fit better and can be faster. For example messaging/serialization frameworks like Apache Thrift or Protocol Buffers.
Anyways, if you go the HTTP way:
Sometimes it's possible to model method-like endpoints as resources, but doesn't always work. If there are no resources, just call it a "Web API" and only keep RESTful concepts and best practices that make sense for you. Caching, nice URLs and leveraging HTTP status codes and header for example.
JAX-WS isn't limited to transferring XML. It it's based on WSDLs though, which you might not need. REST API are easier to handle and more flexible.
JAX-RS is a good choice to build any kind of non-WSDL Web APIs. It provides a clean API and a lot useful features, even if you only use it for simple GET/POST operations.
I want to implement REST service in gwt .But I don't know how to go about it. I read some documents where they have implemented it using RestyGwt and jercy. But I have one app which is deployed on tomcat. Then situation is that my client side app is calling the methods on the application present on tomcat.
I have to implement it using REST so that my client side call will first go to Proxy service on client then it make REST call to the application on tomcat and fetch result and return. How can I do this in gwt. ?
As mentioned, you can only communicate with REST service.
Anyway, maybe take a look on dispatch concept in GWTPlatform and their way of implementing it. (https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch).
Idea is easy, you have an action on client side which is registered to deal with rest url. You can define action interface with some additional annotations to tell what is excepected to be send and received. They are using piriti library for json serialization.
It is up to you if you need only client side implementation or you would like to use server side service creation too.
You can NOT implement a REST service in gwt, since gwt is thought as a client-side solution.
What the GWT kit provides for server side are a few utilities to facilitate the comunication between client-side and server-side when both are written in java (RPC, RF).
So you can consume a REST service from gwt (RequestBuilder, gwtquery-ajax, etc), but if you want to provide REST services you need a 3party solution for your server side like Jersey, CXF, etc.
There are, though, 3party solutions which provides the server side and client simultaneously like restygwt, errai-jax, etc.
If you are looking for a simple and reliable solution to query rest services from the client, in this question you have a client implementation done with gwtquery (ajax, databinding, promises)
I'm learning how to develop with OSGi in recent days, but facing a lot of problems.
I don't know how to design my client-server system based OSGi with Equinox as framework. Should I use socket connections to implement this or use a distributed model?
I'm also confused whether I need to import some third party packages to support my programming on socket, jdbc, swing, etc, or there're existing packages offered by Equinox or other OSGi open source projects?
First time to ask questions here, can anybody help me?
just take a look at OSGi Remote services implementations (more details in OSGi spec):
Web services (Apache CXF: distributed OSGi) - http://cxf.apache.org/distributed-osgi.html
Eclipse Communication Framework - http://www.eclipse.org/ecf/
Cheers,
Dmytro
The HTTP model is probably the simplest to implement, as opposed to protocols based on low-level socket handling and binary protocols.
The first question I'd ask is what kind of information your clients and server need to exchange. If you can live with HTTP (and in many cases you can), you can just use servlets on the server-side, http client libraries on the client side and a RESTful communications model.
Servlets are easy to implement in OSGi using the HttpService, see for example http://www.osgilook.com/2009/09/08/osgi-http-service-registering-servlets-on-the-fly/
Working with sockets is not more or less complicated in OSGi than it is in 'plain' Java. You design your application in much the same way as you would normally, but gain the benefits of modularity and services by using OSGi.
You could, for instance, decouple connection acceptance and request handling by introducing something like a WorkerFactory, or maybe reuse services on both the client and the server; those are the things that OSGi is good at.
OSGi as a 'technology' (as far as that notion holds water) does not mandate any specific interaction method. The compendium specification mentions Remote Services (a.k.a. Distributed OSGi), but it also contains an HTTP service specification is Servlets are your thing.
In short, just pick the interaction solution that best matches your scenario, and let OSGi help you with the services and modularity.
Is there a way to implement RESTful WebService using Spring 3 (or not) that does not use any web container?
Thank you !
I assume that the RESTful request will arrive over HTTP? So something needs to listen on the appropriate port and dispatch requests off to the service code. Obviously you can write such code, but you are likely to end up with something not very different from a Web Server.
If your objective is to embed this capability in some context then a lighweight container such as Jetty (as proposed by skaffman) seems like an answer - I'd be reluctant to write my own code instead
Using a framework such as JAX-RS makes writing REST services very easy, so if the actual objective is develop RESTful services quickly then I'd be prepared to live with a container that does the work for me.
In theory, yes - the various Spring-WS components are decoupled from the Servlet API. So you could, in theory, use the webserver built in to the Sun Java6 JRE.
In practice, this would be a lot of extra work. You'd have to bridge the Sun Web Server API to the Spring-WS API.
As an alternative to traditional Servlet containers, I can highly recommend Embedded Jetty, where your app can start up a lightweight servlet container within itself, and serve Spring-WS from that.