I am developing a Windows Service that uses TCP/IP to communicate with their clients.
So i create a project for the service using Maven. Now i need to create a client to comunicate with this service. Is it better to create another project or a module? Or create it inside the Windows Service project?
For development purposes it easier to create another module. First, its easy to view both client and server code in the IDE without having to close and open projects. Second, common code can be placed in another module, which makes easier to code and debug.
Related
I want to add a mule flow developed in one project to another project i.e wanted to use the flow created in one project in another project like flow reference.
If I am understood your requirement correctly, Your trying to access one mule flow that resides in one project from another project mule flow.
If yes, then you can't use mule flow reference component to achieve this instead you can VM component.
Mule introduced concept of Domains in mule run time version 3.5 and mule anypoint studio with run time version 3.6.
With Domains concept you can access flows across projects using VM component. Go through the below Mule documentation link that will clearly tell you on how to
https://docs.mulesoft.com/mule-user-guide/v/3.7/shared-resources
1) How to create Domain application.
2) How to create Shared components in Domain.
3) Creating application that uses shared components in Domains.
4) Deployment of Domains etc ..
You can manage your projects via Maven and package reusable flows. Mule can then use any of these flows imported on the classpath: https://docs.mulesoft.com/mule-user-guide/v/3.5/modularizing-your-configuration-files-for-team-development
I want to write an Android app that is able to communicate with an application on a server pc, using java sockets.
I have created few classes that implement the Serializable interface, in order to send them through socket as protocol.
The problem is that I have to create two projects in Eclipse, one for the server application and one for the android app. So, I should create a duplicate of those protocol classes in order to use them in both projects.
Is that right? Is there a kind of "import project into another project" so that I can keep those protocol classes in a third project and import it in my android app and server application?
Thank you.
You don't actually need to create a separate Eclipse project for the shared classes. You can just create a 'common source folder' outside of the other two projects' disk hierarchy. For both the server and client projects. In the Properties/Java Build Path/Source add a 'Link source' to the new folder.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
Can any one tell me how to public the wsdl file ie., that web service is created in java using eclipse.I am self learner to java/eclipse and web service too,so can any one please make me clear with steps.
Thanks for your time!...
Apache Axis has some cool tools that I frequently use - to generate a wsdl, use java2wsdl. It has a command line version, but also a Maven plugin (which I highly recommend) that will re-generate the wsdl for you automatically each time you package your web service.
What's more, the axis stuff also provides auto-generation of client stubs by which you can use your web service in consumer apps or services. Alternatively, JAX-WS tools can be used for this as well. In either case I would recommend automating the process with Maven.
If you package your wsdl with your app in this way (rather than letting a server do this for you automatically), you can be certain that your contract will look the same on any platform.
I have two java projects. From project1 I have to call a method of project2. Both the projects are developed using the core java concepts and running seperately. As I know that in this case I will have to use any techniques that remotely invokes the methods(Am I correct?), like RMI, WebServices, JMS etc. I have to very frequently call the method of project2 from project1. What could be the best possible way to achieve this.
Thanks
Are your projects deployed to an application server or servlet container?
You can use web services to expose the method from Project 2. This would be standards based and would allow non-Java projects also in the future to access your service if required.
If it works for you, try to implement it in an asynchronous mode for better performance. Web services allow for asynchronous mode of invocation as well. However, for this, your Project 1 would also need expose a callback method.
EDIT:
I had come across that in Java 6, you can deploy web services outside of servlet container as well. Below link can help.
Standalone web services in Java SE 6
However not sure if this can be used in production environments.
RMI is used in Client-Server architecture. There will be a server program that will implement your interface extending Remote and it will have definitions or calls to other methods at server and it will bind an object. Then you will need a client program that will look up for that object and using that object, it will call methods on Server.
So if your projects are running as Client-Server then you can try this thing.
Next thing you are talking about is WebServices. WebServices provide access to some code written at server to its clients over a network via specific protocols. In this your code will be running on a server and you will access it from your client using Web Service.
Now it is up to you what kind of architecture you are following for your projects and which method is more useful and suitable for your scenerio.