I have developed a web application with Java EE, which connects to a DB. The app is deployed on Tomcat 8. The app is divided in three layers: db layer, business layer, and presentation layer.
Now I need to develop a RESTful API that will use the business layer and will provide most of the functions that the presentation layer provides. Clients will have two options to choose from: open a browser, connect to the APP and use it or consume the RESTful web services from their own software.
My question is: should I deploy the RESTful API on the same server where the APP is deployed or separately? What are your suggestions?
And, what kind of authentication would you suggest for the REST web services?
Thanks!
It is a rather broad question and the short answer is it depends.
Functionnally, you have three parts here:
the presentation layer
the API interface
the back office: business and db layers behind the 2 first ones
Common technical architectures are:
one app for the API and business and db layers, one app for the web layer using the API
everything (API, Web and business) on the same application.
The former offer a better separation and can be interesting for heavy loaded applications, or if you plan to move to a javascript interface (AngularJS ofr example), the latter will be simpler to implement.
For the authentication, it is simpler to pass the credentials along with each request for an API, but you should considere managing it outside the application itself through filters and/or AOP concepts. Spring Security is an example of how this is possible and gives a very loose coupling between the business code and the authentication and authorization ones. You can then choose and change your authentication methods with little impact on the core of the application.
Related
Supposing a classical 3-tier JavaEE architecture like this
JSF / JSP / Servlets (Web)
EJB (Biz)
DB (Persistence)
All JavaEE tutorial examples show the web and biz layers in different containers, but in the same JavaEE server.
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine? In this case, supposing they're going to communicate with the web tier via RMI, is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine?
Sometimes, specifics non-functional requirements can determine your app design.
For example, security: in order to achieve some security norms, the business layer has to reside in a more secure server not exposed directly to Internet.
Availability: if your business layer exposes some services consumed by a different client than the web server, and these services offer some kind of mission-critical functionality, probably they need to run on a 24/7 server.
I'm not sure that think in terms of "advantage" is the correct way to see this kind of decoupled architecture.
I think that is more like a price (which is translated in a more complex design) that you have to pay if you need achieve this kind of requirements.
is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Yes, for example OpenEjb.
We are evaluating one design for educational activity. We would like to create complete backend (which handles business logic) in form of RESTful web services.
These services can be used by various apps. Is it good idea to call these web services from Struts 2 framework? I read couple of docs, and people discourage it.
We would love to go with Struts 2 as team is quite strong on it. But if its bad approach, we may consider for other options.
If you want to leverage development on presentation layer between client-side and server-side (this is where Struts2) then you can utilize web services using a web services client API. At this point these web services can be used as data resources.
If you want to stay only on client-side then you don't need any server-side framework for the frontend development.
Note that The introduction to Struts2 and RESTful applications you have posted in comment introduces an alternative way instead of web services for creating backend in a form of RESTful API using Struts2 framework.
Using Struts2 for the REST instead of web services could be a solution for RAD (Rapid Application Development). Because web services are very complicated technology that used in upper high level architectures and using some alternative resource APIs might be cost effective.
I am planning to start a project and I am looking for the best approach to make a RIA application using AngularJS.
Right know I am pretty sure of those technologies:
AngularJS (+ bootstrap CSS) for the client UI, logic and server
requests.
Spring for bootstrapping the server business logic.
Hibernate + MySQL for persistent data access
Jersey for the Restful web service API.
Spring Security for url and data protection over authentication.
The only piece I feel is not ok is that my application will not be the typical one page app, because it will be large and I want to break it into multiple one page apps, some protected and others public. To serve every index.html I want another technology like Spring MVC, making those small one page apps secure for this points, and also not allowing the access to some resources.
¿Do you think this is a good approach or you would change any of this technologies (like supressing jersey/Spring MVC redundant dependencies)?
i think that in general your aprroach is a good one, but maybe you could use the webapp generator yeoman with the JHispster, a java web app generator.
Or if you don't like the ideia you could add to your data access layer the Spring-Data-JPA, because you will avoid to write the boilerplate code.
I want to create a web service (SOAP) under Apache Tomcat with Axis2, and I must respect the three-tiered architecture:
DAO -> Business Logic Layer -> Presentation Layer
I'm new to web services. Is there a step-by-step tutorial for this?
There isn't really a presentation layer in a web service, unless you consider the service itself to be the presentation layer.
http://www.roseindia.net/webservices/axis2/
There is tons of DAO information on the web, and there's nothing special about a DAO layer for a service versus any other application. A lot of this will depend upon how you want to build your DAO layer. I like using Spring JDBC.
Three tiered architecture means different things to different people.
One common interpretation is (with tiers from the user starting with #1):
Presentation layer running in the browser. I.e. Javascript (possibly from some framework such as jQuery, GWT, etc).
Business Logic layer running on the server. I.e. A dynamic web server (Tomcat in this case)
Database such as MySQL, SqlServer, Oracle, PostgreSql, etc.
It's also possible to have a layer #2.5 doing the DAO work for you (or a custom DAO) such as Hibernate.
Another interpretation is that #1 is actually the web server, and #2 is a separate business logic server, where #1 and #2 live in separate server instances (likely on separate machines or VMs) for security, isolation, and the ability to scale and release separately (and many other motivations).
In any case, you should read up on typical Java serving architectures and possibly describe your goals better. I.e. you use "Presentation Layer" which in some definitions doesn't make sense for a non-UI based web service. Of course, Axis2 could be your "presentation layer" for a web service as well :)
I am building websites in spring MVC. as there are many spring projects , i wanted know what will be scenario when spring web Services is used for.
i mean what can be done with that. Do i really need it for ecommerce site
Your question is really about "web services". For a layman's explanation of what it is all about, read this Wikipedia article.
There are a number of related acronyms that get bandied about:
SOAP (Simple Object Access Protocol) is a protocol for sending requests to a service and getting back a response. The messages are encoded in XML, and send over HTTP.
WSDL (Web Services Description Language) is a service description language for SOAP-based services. It does things like specify what is in the messages, and how the messages are bound to services.
SOA (Service Oriented Architecture) is essentially a system architecture in which the system consists of lots of SOAP services (and others) described using WSDL.
(The proponents of SOA talk about "design principles", but in my cynical view is that this is just a repackaging / recasting of stuff that people have been doing for 20+ years under other names.)
Do i really need it for ecommerce site
Ask your customers. Ask the people whose systems your system will be interfacing with. Ask the vendors whose components you intend to embed in your system.
If you have to use WS then what extra facility it will give
If you have to use WS (e.g. because your site needs to talk to other services that require WS), then you have to. That is sufficient justification.
If you don't have to use WS, then you need to balance the advantages of using WSDL + SOAP against the advantages of some other approach to implementing your web APIs. An SOA expert will probably say use SOA; an AJAX expert will probably say otherwise. And there are other remote procedure call technologies around ... if you really need that kind of thing.
WSDL + SOAP certainly does have some advantages; e.g.
machine readable specifications for your web APIs,
possibility of validation of messages against XML schemas,
an ecosystem of existing WSDL services,
adoption in some sectors of IT.
But it has downsides also; e.g.
WSDL + SOAP have a significant learning curve compared to some alternatives,
XML is a heavy-weight encoding scheme - relatively expensive to parse,
SOAP only pretends to be type-safe (compared with say CORBA / IIOP),
SOAP is not usually used* in browser-based clients; JSON or plain XML are commonly used for AJAX apps,
many people think SOA is over-hyped and steer clear.
* However, it can be used; read these IBM DeveloperWorks Articles.
My advice (FWIW) if your system is primarily a website, doesn't need to talk to SOAP services, and doesn't need to provide a SOAP service API for others .... don't bother. You can always add SOAP service APIs later if you need to.
Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
More here : Spring Web Services
How to use Spring Web Service : Spring WS
If you don't know what Web Services are, you probably don't need them. Web Services are a way (speaking generally here) for one web application to talk to another. You can formulate a request as an xml document and send that xml to a web service, which is listening on a specific URL and port. The Web Service can then perform some action based on this document, and respond back with an XML document. It's commonly used as a means for integration between applications.
If you're building a simple e-commerce site, which does not integrate with other live web products, then likely you don't need Web Services. Spring Web Services is simply an API/library to make reading/writing web services easy.