We Keep Coding

RESTful and J2EE

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.

EJB3 Enterprise Application As Portal & Client Web Apps - Architecture/Design

As shown in the above pic, I have a EJB-3 Enterprise application (EAR file), which acts as a portal and holds 3 web applications (WAR files) that communicate and transact with the same datastore. These 3 webapps are not portlet implementations, but normal webapps which interact with the datastore through the Enterprise App's Persistence Layer. These webapps are developed independently and so, some of 'em use Webservices from the Enterprise App and some of 'em use EJB-Clients.
Also, there is an other option of replacing these webapps (Web App1, Web App2 and Web App3) and using independent Enterprise Apps to communicate and transact with the database, as shown below:
Now, my questions are:
1) What is the best Option among the listed 2 options (above)?
2) How does it affect when we replace those webapps acting as clients to the Enterprise App, as independent Enterprise Apps (EAR files)?
3) What is a better model for Transaction handling, SSO functionality, Scalability and other factors?
4) Are there are any other better models?
EDIT:
1) In the first model, which method is a preferred way to interact with the EAR file - webservices or ejb-client jar file/library (interfaces and utility classes)?
2) How do both models differ in memory usage (server RAM) and performance. Is there any considerable difference?

Since you are being so abstract I will do it as well. If we remove all buzzy words as "Portal", "Enterprise Apps" and so on... What we have at the end is three web apps and a common library or framework (The enterprise App).
Seeing its app as simple as posible. You have three developers that need develop three web apps. You will provide some common code useful to build their apps. The model you will use will depends of what kind of code you will provide them.
1.- You will only provide some utils, and common business code. May be the clasical library fit your needs. (In Java EE environments you must take in account how can you take the advantages of persistence cache level 2 sharing a Session Factory for a single datastore)
2.- You will provide shared services as persistence, cache, security, audit, and so on... You will need a service layer as the first option. You will have a shared state so you need only one instance.
3.- The more common case is both you provide some business API and a service layer to common services.
You aren't indicating any requirement that force you to use a more complex solution for your scenario.
EDIT:
About if it is prefered rmi (the ejb-client) or webservices. I always use rmi to communicate applications geographically close. It use is simple and the protocol is much more faster that webservices (you can read a lot of comparison over this topic searching for rmi webservices performance on google).
On the other hand rmi is more sensible to network latence, require special firewall configurations and it is more coupled that webservices. So if I pretend to offer services to a third party or connect geographically sparse servers I will prefer webservices or even REST.
About the last question initially there is no any difference about deploy one or ten applications in the same server. The deploy fee will be insignificant over the overhead for the use of the application. Of course, you must take this as a generical assumption. Obviously the size and how you deploy your applications will have an impact about the memory consumption and others.
You must take in account that this decisions can be easily changed as you will needed. So as I said you could start with the simple solution and if you encounter a problem deploying your applications your could restructure your ears easily.

I'm inclined to agree with Fedox. If there is no reason for choosing one solution over the other ( business reason, technical reason, etc) then you might as wel choose the path of least resistance. To my mind that would be the first solution.
In general terms start simple and add complexity as you need to. Your solutions have no meaning without context. A banking app needs different considerations to a blog.
Hope this helps

There is a new platform called Vitria's BusinessWare, it's a very successful project which is worth millions.
Now let's see how does it work and what it does so that we can do the same in theory:
It interconnects projects with their databases, web-services with their EJBs..etc.
From their concept we can learn the following:
Create main EJB stateless bean (API), whose job is to pass messages
from:
web-services to other web-services
web-services to webapps
webapps to other web-services
The purpose of this EJB is first do validations in the main database
and then pass the calls to the other modules.
Only this EJB has access to the DB to more secure the connections
This EJB will queue the messages until the modules to sent are free
to accept
This EJB will control all the processes in the DB
This EJB will decide where to send the messages

Usage of a Data Access Layer (DAL) in a SOA design

As we are in the beginning phases of rejuvenating our application in to SOA design I have some questions that I can not get a clear answer/picture on.
I have been doing a lot of reading, mostly around books from Thomas Erl and following that design pattern of understanding what Task Services, Entity Services and Utility Services are.
What I am stumbling on is the whole DAL concept of how that would look. So this is more of a verification of understanding or a clarification so as to help make the best approach for our platform.
So background. We currently have several web based e-commerce applications that have been pretty much been built in silos and are again pretty much a copy of each other. We have supporting applications such as Daemons and misc web services out there. Many of these applications are older then 5 years and are build on only technology (Model 1). All of our applications are centered around conducting auction sales. So during a sale event we will be taking bids from users, determine who is winning and display that information back. Each sale event has a set amount of time that they will be available to the users.
The company is moving towards a SOA solution as a lot of things we end up doing can be shared across not only our group but across other groups.
So what I understand on the DAL is that it in itself is a service which will sit on top of Data, in this case different Databases - MSSQL, ORACLE, MSSQL. Each of these databases have different schema's (Oracle) etc.
So the services (Task, Entity, Utility and Presentation Tier if needed) will make calls to the DAL to retrieve data. It is the responsibility of the DAL to know, from the contents of the message to determine what it needs to do in order to fulfill the request.
So for example, we have a Security Service candidate. This service needs to authenticate with LDAP and to authorize from the data that is stored for that given application.
The thought here is that a Utility service will be created to wrap up all the operations required to communicate with LDAP and that the Security Service will call upon the Utility Service and to the DAL to fetch the authorization data. The DAL then has the responsibility to go to the correct database/schema to retrieve the information. The information will be in XML format (standard SOA communication).
So, am I on the right track here? Have others done similar things or not? What other things do I need to consider (Currently getting the statistics on how many bids we take in an hour - on average).
Should each service have its own DAL - for example should the Security Service have the DAL as part of the service or should DAL be a shared service in which all services can use?

In your case, the approach to use for a full SOA based deployment would be to use an ESB, Identity provider and a data services solution.
To break it down, the DAL should be implemented using data services, in this way, this service will be a globally accessibly service in a language neutral way, and will support re-use and loose coupling. So all your data access logic can be implemented as web service operations in a data service.
So for the authentication and authorization management, in the SOA world, there's a standard called XACML, which is used for fine grained authorization management. So what you will need is an XACML server, who would authorize the user according to a specific criteria, where this should also have the ability to authenticate with LDAP.
Then your "Security Service" will be implemented in a service at the ESB, where that service will query the identity provider for authentication/authorization and according it's response, it will call the appropriate operations in the data service, with suitable parameters to fetch the data, and return it to the user.
The above scenarios can be implemented using WSO2 Data Services Server, WSO2 Identity Server and WSO2 ESB respectively, which are open source products, and can be freely used and found here.

i once worked with (developing) an soa project that used a "data service". it was some time ago, and i was only involved marginally, but my recollection was that it ended up being too complicated and slow.
in particular we had no real need for a data service - it would have made more sense to have placed the same abstractions in a library layer, which would have given better efficiency and no real loss of functionality (for our particular needs). this was exacerbated by the fact that the data tended to be requested in many small "chunks".
i guess it comes down to the trade-offs involved in the implementation. in our case, with a relatively closed system and a single underlying database technology, we could have easily exploited the support for distributed access that the database provided; instead we ended up duplicating this in a slower, more general, message bus, which added nothing except complexity. but i can easily imagine different cases where access to data is more "distant".

How you have to use SOA for your design is depends on the its requirements.
In generally you can write coarse grain services and expose them as web services. In your case you can write some services which calls the databases and produce the results. In this case authorization logic can also be written with the service logic.
The other approach is to use an ESB or BPEL engine to write the integration logic and expose the integrated service as a web service. In this case you can use some data services to expose data base data in xml format and integrate them. You can use services for different sachems and call the correct service with the request data. And the authorization logic can also be added to service integration logic.
Security aspects such as authentication, confidentiality, integrity is considered as non functional requirements and hence can be engaged to any service without writing an explicit security service.
Following articles describes such sample possible integration of services as mentioned in the second approach.
http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
http://wso2.org/library/articles/2011/06/securing-web-service-integration

Web Service vs TCP/IP Sockets (Java) + SQL Connections

We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez

It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.

How to build a three-tiered web service

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 :)