Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
When one wants to set up an API for a webservice with Java EE, what is the best procedure to design and realize such an API?
Having never used persistence before, I always drew out my UML datamodel and structured a database with a SQL client tool then build my application on top of it.
I get the idea that most Java EE applications are built starting from entity classes and services. Or from XSD and WSDL files. Is this true? Is there a difference between how one best creates SOAP and REST apis?
Where is the structure decided and what comes first? How are persistence systems best designed? And on what basis? What tools are helpfull? Any extra information and especially reference is desirable here! I just want to get more feeling with the bigger picture.
It's still a good idea to figure out the correct data model first. The other thing you need to figure out before starting to code is the interface architecture: what calls you are going to support, what arguments the calls will have, and what data will be returned. Once you understand those two things, the actual Java coding can go much more smoothly.
If you are just asking for how to get started with developing a java rest api, I would first look at some of the specifications.
If your question is just about technology to learn, Heres the general stack I use:
RESTful services are provided through the JAX-RS API through the reference implementation Jersey
Object to relational data mapping provided through the Java Persistence API via Apache OpenJPA (almost a reference implementation, little less cruft than hibernate)
Object serialization/deserialization provided through the JAXB API via the Jackson Object Serialization API
Configuration and dependency management provided through JSR-299 via Google Guice
If your question is about API design...
Make sure you write down your api. Make sure the urls make sense, and that you follow best practices when making a url. Your interface between the outside world and your software is that URL. The json you expect and the JSON you return is the most important thing to get right. Even if your software sucks, so long as your api is well thought out and the contract is sound, it will be okay.
Make sure you really understand what you want to input and output before you put it to code.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have 15 services build with Java Spring, they talk each other using REST .
Each time we add a new service to the pool we create from scratch all the code, including rest client code that will talk to other Services and the POJO classes used to map the resource(s) being requested.
We end up copy and pasting from the source code of other services into the new service.
I think it would be better to put all these POJO's and rest client code into a library for all the services to consume it, it would save us a lot of work coding, but "they" say we should not do that with microservices.
So, why is that?
We end up copy and pasting the exactly same code over and over again, I don't see the difference.
I would say "they" are wrong and you are right. There are several issues with copy and pasting client code:
If there is a bug in your client code, you will have to fix the bug in 15 places instead of just 1.
It slows things down. You now have to test and maintain multiple copies of the same code.
It is common practice to create client libraries and distribute them via a standard dependency manager like maven. Amazon does this https://github.com/aws/aws-sdk-java along with virtually everyone else.
In summary, you are right and Amazon is the strongest example supporting your opinion. They do exactly what you are suggesting for their web services, and they are arguably the largest most powerful player in the microservices space.
Also to address the concern of tight coupling in the other answer. Good apis are backward compatible, so a change to the api would not require upgrading all the clients even if they use the same client library.
The main issue is coupling. Sam Newman, author of Building Microservices puts it well:
In general, I dislike code reuse across services, as it can easily
become a source of coupling. Having a shared library for serialisation
and de-serialisation of domain objects is a classic example of where
the driver to code reuse can be a problem. What happens when you add a
field to a domain entity? Do you have to ask all your clients to
upgrade the version of the shared library they have? If you do, you
loose independent deployability, the most important principle of
microservices (IMHO).
Code duplication does have some obvious downsides. But I think those
downsides are better than the downsides of using shared code that ends
up coupling services. If using shared libraries, be careful to monitor
their use, and if you are unsure on whether or not they are a good
idea, I'd strongly suggest you lean towards code duplication between
services instead.
https://samnewman.io/blog/2015/06/22/answering-questions-from-devoxx-on-microservices/
I agree with the statements about coupling. I'm forced to use a specific set of Maven dependencies in a reuse scenario, and no one is allowed to update them. The result is that creating new services gets harder because the frameworks are out of date, and so is the documentation.
On the other hand, code reuse can save a lot of time and money, especially boilerplate code used in services, if it is well constructed and has proper tests.
I think there is a middle ground here that involves versioning and a certain amount of routine maintenance.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to create the back-end framework for my website using one of the following: Groovy Grails or Java.
My main concern is scalability/performance and the app will be able to handle large sets of data, primarily read heavy.
I will be using HTML5/JavaScript/Jquery for the front end and MySql but not hibernate spring JdbcTemplate
Any info would be greatly appreciated, I am fluent with Java and Spring and have made a few small apps with Groovy/Grails.
Edit: Some more specifications: I have to use java mails
I would suggest you to go with Groovy Grails. Simple reason, which you might be aware of as you have developed Grails application, is that Grails follow Convention over Configuration which simply means less configuration (unlike Spring and Hibernate), less time, less work and more output.
Keep in mind Grails under the hood is SPRING and HIBERNATE. So whenever you write a GORM query it would be better and optimised than writing everything yourself. Expect it to be highly scalable with very good performance if you follow the best ways for your DB calls. In any case it would be very easy to write and in the long run the Grails stuff will be much more maintainable as well.
Regarding front end, you are free to use HTML5/JavaScript/jQuery in a GSP page with lots of helpful Taglibs prebuilt for you. You might design one Taglib if needed. On the other hand even if you wish may be now or later, you can even use front end frameworks like AngularJS along with RESTful services on your server.
Regarding Java mails, you can use it or any other library in Grails which you have in Java.
Regarding your fluency with Java and Spring, it is going to take some days to be fluent in Grails but once done then in next few days you will make up any lost ground.
Apologies if I am digressing a bit, I have been a great fan of Servlet's and Spring's of the world (not much of groovy/grails), but recently did a POC on a product idea and used Play/Scala (or java) combo to greatest benefits and to summarize it -
Play! keeps you on the right track, forcing you to carefully consider your memory usage, which produces first-pass code that is practically cluster ready.
So, essentially, with Play/Scala scalability/throughput is not an afterthought rather built into the way we program on it. Hope it helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm starting a new web based enterprise application, and I'm thinking of using Wavemaker.
I'm a fairly experienced java-ee developer, but it seems to me that even in this case, WaveMaker still makes sense to develop the application fast and focus on the business logic.
My questions are :
1- Are their any drawbacks to this platform
2- Can I do all the normal things from the server side easily (like sending mail,building birt reports, adding jobs)
3- Can I freely manipulate javascript (for example for specific animations, using plugins....)
4- Can I integrate realtime processes, like websockets ?
Thank you
I've used Wavemaker in an Enterprise application with success. We used quite advanced features such as heavy use of backend logic based on JavaServices, an run-time SQL database selector made inhouse, JS plugins for the frontend, obfuscation etc
We later recruited a devteam to take support of this application and, although the community is small, the team learn quickly and was able to maintain the code base.
As I see it, Wavemaker is a excellent tool if you like to:
deploy a web-based CMS for your midsized SQL database
deploy a smaller web control page for your java back end system
To answer you questions:
1) Small community: Although the community is friendly and on their toes, it is too small to ensure the type of feeback you might be used to. You will have to spend quite some time banging your head to the wall when you try to go beyond the example applications.
2) Yes, you have all the freedom you would expect from a Java backend. Simply said; each REST api is assigned to a Java Method, its up to you to implement the logic. I have built wavemaker on SQL, mongoDB. With email interactions, data parsing, file upload/download etc You name it
3) Yes, you can add JS plugins and customize the scripts generated by Wavemaker. You might want to make sure that you don't edit the auto generated JS, since they will be overwritten. but as soon as you found the right entry point you are free to customize just the way you like it.
4) Yes, since you build you own back end in java you are free to open up any type of communication you like to have. And since you are able to customize the front end js you will be able to read this data. But as I said in question 1 - there will only be a small community helping you
So to sum it up:
I vote for Wavemaker, but make sure to only deploy it if you application will be similar to the templates/demo provided, if you build a unique system you might like to look into other solutions.
All choices have drawbacks. There is not a lot of WM expertise to be had. You'll need to deal with some issues in terms of the library at hand, dojo, spring etc instead.
you can,but it requires some java knowledge. You are operating in a spring MVC you can
you can, you are operating in a dojo client there
possible, probably. worth the effort, doubt it.
1- Drawbacks- It's enterprise focused platform, so will require own effort to learn it.
2- Yeah, you can do pretty much all normal things (at least from my experience, till now)
3- The tool has kind of open-source configuration so its easy to manipulate or customize your codes if needed
4- From my experience, WaveMaker has one of the best and most diverse integration options available.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I am new in web development world
(from microcontrollers to web is a really long path)
Having a Java software (.jar) running, it's just a background process sending/receiving info through sockets, with no interface.
I would like to make a web interface to it, and I need some guidelines, about how to confront these topics
The code:Should I keep it being .jar or it's recomendable to go into .war and deployment? other?
The html/javascript code:Edit the page with an wysiwyg editor? and/or edit the html code within IDE ? / use GWT to develop everything within java? other?
The http server: Use an Apache Server, tomcat? implementing it within java with HttpHandler? other?
The Data: Data is actually in classes, objects and some persistence with writeObject.. should I leave it that way or "web development" is compatible better with mysql or some sql? other?
Just searching for something simple and actual tools, and to avoid reinventing wheels
Experienced web developers, your advices are very welcome!
I would suggest that you embed Jetty and then add some servlets to connect your existing code.
It really works !
If this is an accurate summary
You have a (presumably) proprietory protocol exposed over a socket interface.
You desire to access the same function over HTTP, with a Browser based GUI.
Then I would approach it like this:
1). Consider whether to refactor your current code - In concept you have a "core" with a socket interface. What you need is the same "core" with an HTTP interface ... except maybe that doesn't nicely work? HTTP is effectively stateless, with request/response pairs. You might have something much cleverer with your sockets so some redesign might be needed, or maybe it just fits, or even you need to get really clever and use streaming, or Comet or something.
So first decide on an approach. Let's take the optimistic assumption that a standard HTTP model works for you. Then:
2). You may as well use the servlet API, so TomCat or WebSphere Community Edition or any readily acessible servlet engine will do. Just write a few servlets that front your "core".
3). Tools, Eclipse works. Plenty of alternatives, but favour an IDE.
4). Especially when moving to the UI part, editing HTML, or JSPs something WYSWYG is useful. Things get a bit tougher if you want to do a Javascript-based UI - there are products out there but I don't think they're as mature as things such as Eclipse for Java.
I recently learned Spring. It's a very lightweight framework, and very easy to learn and use.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have not had much experience with Webservices or API's.
We have a website built on Oracle->Sun App Server->Java->Struts2 framework. We have a requirement to provide an API for our system. This API will be used by other systems outside of our system. API is just for a simple SP that we have on our database. The other system does not want to connect to our DB to gain access to the SP but instead and an API as a 'webservice'
Can the community please shed some light on how to go about this? Will the API be put on our webserver? is that how the other system will connect to it? And how to go about creating a public API?
Some things you'll need to think about are:
SOAP vs REST (Why would one use REST instead of SOAP based services?)
How will you handle authentication?
Does it need to scale?
You might want to take a look at https://jersey.dev.java.net/.
It would also be helpful to look at how another company does it, check http://www.flickr.com/services/api/ for some ideas.
If you are using the Sun App Server, it should be fairly trivial to make an EJB exposed as a web service with the #WebService tag, and then have that EJB call the Stored Proceedure and return the data. The app server gives you tools to publish a WSDL which is what they will use to know how to call you API.
That being said, what sounds easy at 50,000 feet is a real pain to deal with all the details. First, what about security? Second, are WebServices really required, or is there a better communication mechanism that is more obvious, such as (at a minimum) REST, if not some simple servlet communication. And the hardest part: In exactly what format will you return this result set?
Anyway, you could be dealing with a bit of a political football here ("what, you don't know how to do web services, everyone knows that, etc.") so it can be a bit hard to probe the requirements. The good news is that publishing a web service is pretty trivial in the latest Java EE (much easier than consuming one). The bad news is that the details will be a killer. I have seen experienced web service developers spend hours on namespace issues, for example.
Soap or Rest or .. is one side of the medal and depends on what the clients want.
The other (more) important thing is the api design itself. Shall it be stateless or stateful. Are clients co-located in the same VM (Appserver) or remote in the same LAN or even in a Wan.
As soon as the communication goes over the wire, it gets slow due to serialization. So you want API methods to obtain bigger (but not too big) chunks of data at a time.
Or in other words, your question can not really be answered without knowing a lot more about what you want and need to do.