I'm developing a server to offer persistence to clients connecting through http. The clients will be based on different technologies: web, iphone and android; that is why I thought of using http in the first place (may be there is a better approach).
In the server I'm using a javaee 6 implementation with EJBs and JPA to achieve my persistence goal and servlets to offer access to the EJBs interfaces to the clients.
The servlets are just dummy proxies, so I'm sure there has to be a framework or a better way of offering my EJB as a service to my clients.
I'm trying to find a way of avoiding all the dummy proxy servlets.
You could implement RESTful Web Services with JAX-RS
Related
Our organization is looking into implementing new internal APIs using GRPC.
Currently, we have a microservice that is serving internal/external requests using embedded Jetty. We want to make internal communication between services to be done over GRPC.
So, we'll have 2 servers running on the same VM: jetty and GRPC. Is it a good practice, any red flags with that approach?
We do not want to split that said microservice into 2 to save costs. We should be able to run the app on the same number of VMs.
There's nothing inherently special or wrong about having Jetty and gRPC in the same JVM. The main point of potential trouble is just that you will have two ports exposed instead of one; that might matter for service discovery or firewalls.
I am new to programming and working on SIP applications. I am bit confused about where to deploy SIP applications. I read about HTTP Servlets, which are deployed in servlet container, I believe Tomcat is one Servlet container.
Basically, I have few questions and understanding:
Container manages the lifecycle of the servlets and if I just get the servlets api jar and deploy it with my application it will not work?
I found SIP servlet API and there's also Mobicents SIP servlets. Are they different?
Can I deploy my SIP servlet application in Tomcat along with the API jar?
Is Mobicent a container for SIP servlets like Tomcat is for HTTP Servlets, but Mobicents also has Tomcat.
These are very naive questions but I tried to find out the answers myself and was not successful. I am not from programming background so having a difficulty to understand the things.
Thanks
I invite you to read the specification at https://jcp.org/en/jsr/detail?id=289 it's not a complex read and will give you a good idea of what you can do. SIP servlets are built off the generic servlet API provided by the Java Servlet Specification but differ from them in a number of ways notably on being asynchronous or being able to generate multiple responses to an incoming request
the SIP Servlets API is defined by the Java specification mentioned in 1. above. Mobicents SIP Servlets is an implementation of the SIP Servlets API specification. It is supported by TeleStax. This is very similar in concept to JBoss Application Server (aka Wildfly) implementing the Java EE Specifications and being supported by Red Hat.
Please download the latest version of Mobicents SIP Servlets on Tomcat. It comes with a couple SIP Servlets application by default. You can also check out the examples, that should give you a good sense of how things are working together.
the SIP Servlets specification mandates convergence of SIP and HTTP so that you can use both in your application and share data between HTTP Sessions and SIP Sessions to create converged applications leveraging both the Web and the VoIP worlds. As such Mobicents SIP Servlets extends Tomcat to provide SIP capabilities to it. So a vanilla Tomcat installation will not support SIP Servlets out of the box, you need to download the specific extended Mobicents SIP Servlets Tomcat Version to be able to use SIP Servlets.
There is no naive questions ;)
Myself and my architect are designing the architecture for one of our products and he suggested to go with Web Api as a Service Layer (because it's a light weight component).
Straight away I'm thinking how it can be used for non-http based clients and also for external clients. How can we provide the proxy information about our API (in case the API is having a complex type as parameter)?
Please advice whether we can use Web API as Service Layer?
Straight away I'm thinking how it can be used for non-http based clients
Well, it can't. The Web API works only on top of the HTTP protocol. If you need to use some other transport protocols such as UDP you might consider WCF instead.
How can we provide the proxy information about our API
RESTful services do not have the notion of proxy information. They should be documented well for non .NET clients. For .NET clients you could share the contracts (Request/Response Dto) between your server and client application. The client application could then reuse those Dtos which may act as what you call proxy and which is something that exists in the SOAP world but not in the REST world.
Is there any difference between
Webservice and WCF
WCF and WCF RIA Data Services
it seems to be the same.
There are quite a difference between WCF and Web Service mostly in performance and security, also a flexibility and portability.
10 most important differences are listed right: HERE take a look!
A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode and transmit application data.
Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).
WCF Service
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.
Check this Link
Asp.net web services are homogenous.
Asp.net web services can use only HTTP chanenel.
Not supports msmq and tcp binding...
WCF is flexible because its services can be hosted in
different types of applications. The following lists
several common scenarios for hosting WCF services:
IIS
WAS
Self-hosting
Managed Windows Service
WCF = Web services + .Net Remoting + MSMQ + (COM+)
http://www.codeproject.com/KB/webservices/WCFVSWebService/WCFVsWebService.pdf
When looking at SOA (Service Oriented Architectures) the main problems seems to be distributing a services load across multiple hosts and then managing these hosts (taking hosts off line or adding new hosts)
When one service talks to another it should not need to know any host information (at the application level). Rather the SOA Environment should be able to route a service request to a specific host based on the hosts current load characteristics (so it must know all hots a service is running on and their relative load).
Are there any existing open protocols for service to report their existence and load to an SOA Environment.
SOA is a set of high-level software architecture guidelines. It is not a technical standard or recommendation and it has nothing to do with technical implementation details, like load balancing.
Load balancing is based on addressing, which is dependent on the service access technology.
Systems built in "SOA-way" may be using different service access technology, like SOAP (over HTTP, JMS, etc.), REST, asynchronous XML messages over JMS, etc.
With SOAP, the service consumer may look up a UDDI registry to locate the service provider. Some of the latest UDDI registry software provide simple (e.g. round-robin) load balancing.
Another SOAP idea is using WS-Addressing, but it is not really meant for load balancing.
I think currently the best place for load-balancing is the underlying network transport layer. With HTTP transport you can choose hardware or software (e.g. Apache HTTPD modules) load balancers that can adapt the distribution based on response times and time-outs. With JMS transport, the most popular JMS servers provide some form of load balancing. Other protocols - like CORBA or Rendezvous - usually require a custom solution.
You can also utilize an ESB software, e.g. Oracle Service Bus or TIBCO AMX Service Bus. With an ESB you can easily create a load-balancing proxy for your service instances. The proxy may be enhanced with some logic, like look-up a database table for guidance.
As you can see, there is no one-size-fits-all solution for service load balancing. The optimal solution will be based on the actual implementation architecture and vendors' recommendations.
After reading a lot the concept I was actually looking for was the Enterprise Service Bus ESP.
Though it does not explicitly define an explicit protocol it defines an architectural style that allows the solving of the problems I stated above.