My Company is going to start new project this year which need to archive web services on it way and I need to make decision on some technical things. After some research on web I thought that Qt and gsoap also can be candidate for the job we want to be done.
We were working long time with Java and C# based web service but now we need to solve two problems mentioned below:
Web service need to be extremaly fast
Easy adding service mwthods to it as we go
To be honest I think that we will not have much work in this side just several service methods to analyze and store data in database.
Thats why, as performance is very important for us we think that Qt + gSoap is option to go with.
It will be very nice to know what to use Qt/gSoap/C++ or Java/Jax-Ws taking in consideration two options listed above?
Thanks in advance
Related
I'm working on an Android app right now that needs to communicate with a MySQL server. For obvious reasons I would like to use an ORM. My problem is that I wrote and tested the backend for the system on my desktop, and this being my first time with Android and backend systems in general, wrote it all to use Hibernate. When I went to load my application onto a phone, I had a great deal of trouble with Hibernate; it is not meant for mobile development.
The way I see it I have two ways out of this hole. Option one: I modify my codebase to use ORMLite (a light ORM that suits Android well). After a cursory glance at the documentation, I see that many of the Hibernate's features that are supported in ORMLite require complete rewrites; there would be very little reusable code. Even the POJOs would need to be rewritten. While this seems like a daunting task, if it is determined that it is the best course of action, I will happily pursue it.
My second option is to migrate my Hibernate code to a Tomcat server (or something of the sort), so that my application can still have all the functionality it has now on my desktop, but outsource the processing. I know very little about Tomcat or JSF applications in general, however again if need be, I will happily pursue this option. I don't even know if this option is feasible! Again, I just need guidance.
So my question is, of the two methods, which would be
The most efficient (in terms of my application)
The best practice (option two may be a major no-no, I'm just not sure)
The smallest headache (I think a headache of some sort is unavoidable at this point)
Thanks in advance for your help!
edit: In response to a comment below, I am not deadset on Tomcat as a J2EE provider. I listed it simply because I knew what it was. Moreover I need to know whether using HTTP output of ORM data (encrypted of course) is a reasonable design decision, or if I should go with the direct ORMLite implementation.
I'm trying to figure out wether I should use SOAP or REST for a specific project. I will explain what the project is or needs to do, and I hope some of you will give me useful information about why I should use one over the other.
The project I need to work on is totally web service based. Every frond end implementation needs to access webservices to get all the information it needs. But Beyond that, we also have an Indesign plugin that talks to these webservices to upload documents and check validations on the document etc.
So to make it short, I need to access the web services via front end web gui's and via an indesign plugin. The latter makes me wonder wether I should use REST or SOAP.
Thanks alot for reading this and posting you feedback.
I found this really great article on the advantages and disadvantages of SOAP vs REST: http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/
And my own humble opionion:
I don't like SOAP, I never did. It's been great at the time, but it just never felt "right". If you've ever tried to read one of these huge overloaded XML-documents and compared it to the REST output (which is JSON most of the time) you know what I mean. IMHO just feels "better".
One problem is that you have to document your REST API better, but that shouldn't be that big problem as long as it is not open to everyone.
Especially if you handle all your data with Webservices, I think you should go with the lighter and less bandwith consuming option: REST.
Also REST is the new and hip technology that everyone uses at the moment... ;)
About your indesign plugin: You should be able to include any library you want, so that shouldn't be a problem.
We're developping a software for a large bank. So, the problem is that bank operates in SOA way. I mean, we have an entry point to the system and then there are WebServices fow everything, and when I tell everything, I mean EVERYTHING, there are like 3500 services.
Right now these services are just stored in a database table with (or without, sometimes) their descriptions, so, you can imagine the hell we're living in. I guess that sometime it's easier to implement new web service than to find the right one, this produces redundancy.
So, my question is, is there some way of organizing this kind of stuff? I mean, we have many bussiness lines and some common components, but I'm totally newbie in WS. Anyway, I need some kind of way to provide the developers with information what service they can use in any case.
A good documentation may help. Or google for the more sophisticated approaches like web service registries using WS-Inspection or UDDI.
I've seen it done with a simple web site where developers can find descriptions, WSDLs, etc. I think it's sufficient; I wouldn't recommend UDDI or buying a sophisticated tool. Yours is a problem in advertising and marketing.
High Level Logic: Rethinking Software Reuse in the 21st Century
http://highlevellogic.blogspot.com/2010/09/high-level-logic-rethinking-software.html
To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
Alright, so I am a compsci college student who, being in college, has not branched out towards a certain specialization yet. I have been programming since I was a young teenager, certainly know my stuff - well versed in about eight different languages as well as compsci theory, etc. In addition, I have about four years of web programming (PHP mainly) behind me, having started freelance work in that area since web 2.0 became hot.
My summer job now as an intern of sorts is to write an application for an industrial, not software-related startup. This application will be used to manage production lines and logistics flow. I have chosen Java for my language because I don't want to shoot myself in the foot.
I am well-versed in the syntax of Java, in its data structures, language theory, and such, but I have absolutely no idea where to start. I can picture the program perfectly in my mind, I understand the problem clearly and got the solution's theory nailed. Namely, I have no idea what libraries to use, and am scared that they won't be well documented.
Here are some general outlines of what I'm going to make:
Two applications, one server and one
client (of which there will be many
copies).
The server and clients obviously will
communicate via (I don't know).
Both the server and the client
software will have GUIs.
The server software will have to
query a MySQL database.
The client software must be 'live' in
the sense that the GUI updates when a
change is made to the database. This
is one of the reasons why it can't be
a web application.
I'm not even sure if a framework is right for me or not. I've used MVC tons of times in my web freelance work, but I dont know how that will translate for desktop applications.
In short, I'm looking for the right libraries for the job, as well as advice on whether or not I should use a framework (and if so, which). Thanks.
This is a summer intern job? To be honest, this sounds more like a major project if you ask me. You say the start-up is not software related? Who came up with this idea? Do they have any idea of the (huge) scope that something like this might actually entail?
The business of software development is something quite different to language syntax and libraries. It's about requirements gathering, defining a spec, writing code, ensuring quality of that code, having it tested and so on. These are not things an intern should reasonably be expected to pick up. For something like this you should be under more experienced supervision, someone you can learn from, someone who has done this before.
That being said, unless there's a really good reason, I would probably do such a thing as a Website rather than a desktop app. Desktop apps are a lot more complicated in many ways. You need to code both a client and a server. Communication is a bit trickier. You have to worry about the issue of maintaining state in multiple applications, how to handle updates being pushed around and so on.
In short, it's a big job. Even a Web site is a big job but a lot of these issues go away. You could do this with Java. I've certainly coded my fair share of Java Websites but PHP might be a far simpler bet.
Also, desktop development on Java is, well, torture. Swing is (imho) tried and true but also incredibly painful to develop in. Other desktop libraries (eg Netbeans RCP, Eclipse SWT) are more modern but have other idiosyncrasies.
Desktop remoting libraries include things like Spring remoting, even Web services and other things like Burlap. For the server side, I'd be using either Tomcat or an application server (Glassfish is my preferred choice), servlets and Spring. Persistence can be done via Hibernate or Ibatis (or lots of other options).
But honestly, the desktop option is so much more complex than a Web-based one. You'd probably get a lot more done faster using PHP + jQuery + MySQL.
If you are doing this keep it as absolutely simple as possible. Try to define the absolute minimum you need to initially deliver and do that. Once someone has that they'll then have a better idea of what works for them and what doesn't. Basically it's easier to refine something that already exists vs define something that doesn't.
I recommend that you only build a web application. A web application can be 'live' in the sense you are describing it by using AJAX. It would be much easier to build just one thing. If you also want to have a rich client, then you need to build the UI in a technology you are not familiar with (like Swing or SWT) and design/implement the communication mechanism.
Have a look at Hibernate (ORM tool) and Spring (IoC framework). They have a somehow steep learning curve, but they will make your life easier at the long run. For the UI part perhaps JSF is easier for a beginner.
As a last note, I think you have an over-ambitious plan. What you are describing is not an easy project and requires expertise with a lot of technologies. Do not try to do everything in one shot.
Java Desktop 6 (JRE)
JDBC (built-in in any JRE)
MySQL JDBC drivers (freely downloadable)
for communication you have several choices: RMI (built-in) however this days I recommend
learning something like Java Web Services (JAX-RS)
Libraries?
JDBC for the database. You may want to look at ORM mechanisms like Hibernate
I would recommend the Apache Commons libraries for all your utility work (handling files, IO etc.). There's a lot of stuff there to save you reinventing the wheel.
A standard logging framework like Log4j will allow you to log in lots of different ways, filter your logs and plug into monitoring solutions easily.
You don't say whether browser-based solutions are acceptable for the client/server GUI, and that decision will drive a lot of the further architecture.
If you're looking at browser-based solutions, then I would advise a grounding in servlets regardless of any framework you ultimately choose (no doubt a lot will be recommended here).
By this stage it's getting to be a major project. Perhaps you need to concentrate on getting the fundamentals (client/server functionality) working, and worry about the GUI later. Otherwise it's a huge amount of work (and GUI work can draw an enormous amount of time).
Just one nitpicking:
Both the server and the client software will have GUIs.
I advice you to have a headless (in awt parlance) server, with an administration GUI, not a GUI-server.
Well this can go as wild as you can think of or you can go and do KISS.
If you would like something that is really simple (as in not using any frameworks):
* In the server side you can use RMI. This server side will use plain JDBC to connect to your MySQL database. But some said that this is kind of old, so if you want to get funky you can try JAX-RS which can return a JSON objects/XML to your client.
* Your client can be made using Swing (assuming you are developing desktop) or Servlet + JSP (assuming you are developing webapp) and connect to your server by calling the RMI objects/JSON objects/XML that is exposed by the server.
If you would like to get nasty which will help you in terms of code maintainability you might want to plug-in Spring + Hibernate into this application.
Good luck!