In my Pivotal Cloud Foundry development environment, I have a Service Registry created and a bunch of services bound.
Seeing as there is no easy way to debug services that are actually running on PCF, I want to bind my local services to the Service Registry I have created my PCF dev. When I have asked how to do this, I have been told that this is basically impossible to do.
So my question is, how do I go about debugging my services if I can't connect onto my Service Registry in Dev? The two possibilities I can think of are:
Deploy a Eureka server locally, as well as all the dependent services I am going to be connecting to. If I have a lot of services I am connecting to, this is going to be a major headache.
While testing, I can change my code and hard-code in a service endpoint of a dev service instead of relying on the Service Registry and Ribbon. This will work, but is very dangerous because I may accidentally check in some of this code.
Is there another possibility that I am missing? Are there any easier/safer approaches?
For debugging, I found using Spring Sleuth Zipkin can be very valuable.
And I hope you are using Spring Registration and Discovery.
Spring takes care of lot of internals stuff for Netflix Eureka.
I suggest, you give it a try, it will make debugging and maintenance a whole lot easier.
Related
Is it possible to run an eureka client without running a webserver? The 'spring-cloud-starter-eureka' artifact automatically pulls in 'spring-boot-starter-web'. Why is that? Is it possible to run the client without actually starting up a webserver?
My problem is that starting up a webserver eats up around ~200mb of ram. This is a problem because the memory allocated for the apps I want to use eureka with is ranging from 256-512mb.
It seems you don't need this service of yours to serve web request but still need the it to access your eureka server.
So disable web from the application.
spring.main.web-environment=false
And use the Discoveryclient to fetch the services.
If that is not good enough then remove eureka dependency and Make a rest call using (RestTemplate) to your eureka server to query for the services you need. Eureka exposes a rest endpoint for this. So it can't be used by even non-java/jvm based applications.
You could take a look at this project I wrote some time ago to see how to do this.
If that is not good enough still. Then you might have to write plain java code which you should be writing in the first place unless you have a reason to be using a framework such as spring (Transaction,JPA, web, security etc).
So, i have some experience developing Java WebServices.
The problem is, all i do is deploy them to localhost.
My question is:
How can we deploy a WebService to a server other than localhost?
How can i search the web and find the WSDL description for my WebService so that i, or anybody else around the world, can call its services?
If i have it in localhost, nobody else but me on my computer can acess it right?...
Thank you for your time
I don't think you'd want to make an application running in your development environment accessible to anybody else around the world for a variety of reasons. Others on your local network could access your local host via its network hostname, but this isn't users around the world.
Let's discuss your two questions individually:
How can we deploy a WebService to a server other than localhost?
You'll want to establish a server environment that is available (on) as much as possible. If you want to keep using Apache Tomcat, you could sign up with a variety of service providers that host Apache Tomcat applications - there are many who offer tiered pricing based on number and size of pre-configured virtual servers (CPU, memory, disk space, and/or monthly data transfer of the application). You could even sign up with a cloud service provider such as Google Cloud, Amazon Web Services, or Microsoft Azure. All provide the tools to build, provision, and manage virtual server(s) which you would then deploy Tomcat and web service application into. Here's a detailed tutorial on setting up a Tomcat virtual server on Azure. You'd then need to manage those server(s), watch them to see how much they're utilized (which will impact how much they cost you per month, by the way).
If server management isn't what you're looking for - you could also explore "serverless" options such as Google AppEngine or AWS Elastic Beanstalk. In this model, you just upload your WAR file and the hosting service manages things like how many servers are needed to handle all the application SOAP requests your users around the world are making. You'll need to read the specifications for each, as you technically aren't providing Tomcat itself - in Google's example, you're actually running in their own proprietary container, so your app may need some changes depending on what it does.
Depending on what hosting or cloud service provider you select, your "how to deploy" steps vary wildly. On the bright side, all offer tutorials on how to specifically deploy applications into them "their way."
How can i search the web and find the WSDL description for my WebService so that i, or anybody else around the world, can call its services?
Once you've settled on a hosting or cloud services provider and have deployed your application, you'll have a URL to reach it, but you'll need to work on getting the word out. There are some open specifications on (SOAP) web service discovery, but more than likely that's not what you're really looking for. You could also submit your WSDL URL to an online API directory such as ProgrammableWeb or Public APIs.
The simplest way to do-it-yourself would be to run a web site that links to the WSDL, then use search engine optimization techniques to list the site on search engines and make it (and the WSDL it links to) relevant to web searches.
Getting fancier, you can treat your web service as a product via an API Management system. At a high level, this works by hiding the real URL to your web service on its server(s) and instead direct clients to a small website for developers where you document, market, facilitate discovery of your service as well as offer a sign up to use it (so you can track and manage who around the world is using your web service). Clients then consume the web service via separate URL behind what's called an API Gateway. You could charge for access or offer it for free but limit the amount of concurrent requests a client can make - after all, you're likely paying your hosting provider for utilization. Some of the cloud service providers Amazon, Azure, standalone API management vendors such as Apigee, Mashery, and many others.
I am a bit lost because it's my first time assuming this role for a project.
We are making a software which consists in an app developed in Phonegap (for making a service oriented architecture, to make multiplatform easier).
The Phonegap app (and also the admin web) will be consuming constantly web services (every functionality is a service), and is my task to set up and environment to publish the API with the different services. I have heard about JAX-RS and also Spring MVC (I prefer this last option, because the good integration with Tomcat, and knowledge on the framework).
I have more or less clear the architecture (Tomcat+Spring+WebServices), but I am not sure how to start, because of the integration with the mobile app. I obviously want to develop with Java in the server side.
Any advice to start or related?
Thanks too much to all.
I would suggest you go for Apache CXF support for Rest Service.You can deploy the same in a tomcat server.I will suggest you to read the following URLs for better understanding:
http://www.dreamsyssoft.com/blog/blog.php?/archives/7-Simple-JAX-RS-Web-Service-in-Java-with-Spring-and-CXF.html
http://cxf.apache.org/docs/restful-services.html
Hope this helps.
I have had lots of trobule trying to get my head around how to solve this scenario:
We have an integration application that uses Camel for integration. This application also has a REST Api that exposes some services providing information about the application, for instance listing the active routes etc.
I have created a user interface for this using AngularJS that connects to these rest services. My main problem is how can I package this application as a self contained jar-file that provides the user interface and all the camel integration.
My working theory: Use a separate Jetty server to serve the Angular JS files and let Camel expose the REST services. The problem with this is CORS since the REST services reside on another port than the jetty server serving the Web UI.
Some requirements for the solution:
Must be a single self contained jar-file.
The camel integration is the main purpose, the Web UI is secondary
and only used for trouble shooting. No need for a high performance
web container since the Web ui is used by only a handful of users.
I have been struggling with this for a couple of days now and it feels like I am over complicating the solution. Help on how to solve this is greatly appreciated.
You could take a look at hawtio
http://hawt.io/
as that is how we do that, hawtio is a web console for java, and has plugins for Camel. Its built using angularjs, and uses REST to communicate with the local or remote Java JVMs. To make the REST calls easier we use Jolokia.
Jolokia requires an agent to be embedded in the JVM, eg where Camel runs. Then that helps with CORS et all. http://jolokia.org/reference/html/security.html#d0e2490
For my web application, I am thinking about using the Spring framework. Initially, I was thinking of having different actions like create user or login, but now I have to expose some functionality to other applications. Should I create a web service that I call from my application and others do as well, or create an action from Spring and then just have others call the web service? It seems like I should minimize the different ways to call something, but does it make sense to call a web service that is running on the same application server as my main app? Would this be a bad idea from a performance stand point?
Update
I was concerned that Tomcat wouldn't be able to serve both the static or dynamic pages on port 80 (so users could go to www.example.com/welcome.jsp instead of www.example.com:8080/welcome.jsp), as well as a web service but I guess it doesn't matter as both are just served as requests from Tomcat. I'm guessing this means I'll have to change Tomcat to run on port 80 and other applications will have access the web service via this port. Or I could leave Tomcat running on port 8080 and put Apache in front on Tomcat on port 80 and Apache will serve the requests to Tomcat. Is that correct?
I'd put the common business logic in a "business service" and :
call it from an action in your web app
expose it as a web service for other applications
To me, there is nothing bad with this approach and it's pretty easy and clean to implement it with Spring. Actually, I would find ugly to expose this business service as web service only and to call it from the web app (and I'm pretty sure that this will be more complicated to implement on the web app side). You have different "usage contexts", just expose the adequate interface for them.
(EDIT: I'm answering a question of the OP posted as comment below)
You can deploy the web application and the web service in the same WAR (but this is just a deployment choice, you could package the business logic in a JAR and use it in several WARs). Regarding the port, I'm not sure to understand your question. Traditionally, you'll use a web server (e.g. apache) in front of your application server. If you don't, you can always choose to run you app server on port 80. Actually, in both case you are free to use whatever port you want. Using port 80 is just convenient.
Yes, your update is correct.