What is the general practise for handling Authorization in a polyglot architecture (e.g. Java and .Net Server)
Can a session be shared amongst the 2 services written in different technology?
Related
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.
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.
It's time to ask question on StackOverflow because I did not find a good one in Google.
We have a legacy systems(2 in my case) that provide some functionality via RESTful web-services.
Now we are building a Java EE system that will consume RESTful services from that legacy systems.
Questiuon: how to build convenient facade API over mentioned RESTful web-services to use them easily in our Java EE app?
Are there some frameworks to easily consume a set of REST web-services and it can be XML-configured?
There is a number of options
The most "low level" - HTTP Client (http://hc.apache.org/httpclient-3.x/)
Something more abstract - RestEasy ClientRequest/ClientRespons (http://docs.jboss.org/resteasy/docs/1.2.GA/javadocs/org/jboss/resteasy/client/ClientRequest.html) there is a number of tutorials how to work with it
You might like it most due to XML config - Spring Framework RestTemplate support (see, for instance http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/client/RestTemplate.html), there is a number of tutorials in the web too.
At work we are developing multiple systems that are highly modular and should not have hard dependencies on each other. Now we need these systems to share a common mechanism for authentication and security - or in other words - SSO (Single Sign-On). It is obvious that we will have to make another module that deals with managing authorization, authentication and security - a SSO module. The point is to have it properly integrated with our other systems.
The two approaches I can think of are:
1) Expose a RESTful service(s) from the SSO that allow the authentication and authorization operations to be performed by the the other two systems.
2) Expose a common API for authentication and authorization that will wrap our SSO functionality and have the two systems reference the API and use it directly.
At the moment we are not considering using any third-party solutions in this area, and we have already done some work on the would be SSO module, so we would prefer to stick to a simple solution that would best utilize the existing efforts.
Which approach should we choose and why? What are the significant benefits of each one over the other? Is there a better alternative?
"should I expose it to REST or have it wrapped in an API?"
Go for the best of both worlds.
Expose the authentication & authorization module as a RESTful service to allow the greatest interoperability regardless of the language, framework, or platform chosen for each of the modules. Anything that can communicate over HTTP could use it.
Then develop a library in your language(s) of choice that communicate with your RESTful service; this will make it easier for multiple modules to use a centralized auth mechanism. So you'll have small clients written in ruby, java, etc. depending on the languages you use for your modules.
This sort of code reuse is one of the key tenants of a service-oriented architecture, and is the way to go in my opinion. A few colleagues and I described this in more depth in a recent presentation based on our experiences at BrightTag and other companies.
Many "enterprise" SSO systems like CAS use a very similar approach (though the CAS protocol isn't RESTful). If you want more advanced features, I would definitely give CAS a look.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A web service is a function that can be accessed by other programs over the web (Http). To clarify a bit, when you create a website in PHP that outputs HTML its target is the browser and by extension the human being reading the page in the browser. A web service is not targeted at humans but rather at other programs.
SOAP and REST are two ways of creating WebServices. Correct me if i
am wrong?
What are other ways i can create a WebService?
What does it mean fully RESTful web Application?
Correct
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network".
A fully RESTful service is one that adheres to all or the architectural constraints as layed out in Roy Fielding's thesis, Architectural Styles and the Design of Network-based Software Architectures. It's a long read and there are many interpretations. A good start would be to familiarise yourself with the Richardson Maturity Model. NOTE: Most Web Services that claim to be RESTful are only at level 2 in that model.
I think that to understand what is a fully RESTful service you have to understand the difference between RESTful services and standard Web Services. It's quite good exaplained in JEE6 Tutorial by Oracle:
NonRESTful WebServices (In Java as JAX-WS): Big web services use XML messages that
follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a
message architecture and message formats. Such systems often contain a machine-readable
description of the operations offered by the service, written in the Web Services Description
Language (WSDL), an XML language for defining interfaces syntactically.
The SOAP message format and the WSDL interface definition language have gained
widespread adoption. Many development tools, such as NetBeans IDE, can reduce the
complexity of developing web service applications.
A SOAP-based design must include the following elements.
■ A formal contract must be established to describe the interface that the web service offers.
WSDL can be used to describe the details of the contract, which may include messages,
operations, bindings, and the location of the web service. You may also process SOAP
messages in a JAX-WS service without publishing a WSDL.
■ The architecture must address complex nonfunctional requirements. Many web service
specifications address such requirements and establish a common vocabulary for them.
Examples include transactions, security, addressing, trust, coordination, and so on.
■ The architecture needs to handle asynchronous processing and invocation. In such cases,
the infrastructure provided by standards, such as Web Services Reliable Messaging
(WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation
support, can be leveraged out of the box.
RESTful Web Services (In Java as JAX-RS)
In Java EE 6, JAX-RS provides the functionality for Representational State Transfer (RESTful)
web services. REST is well suited for basic, ad hoc integration scenarios. RESTful web services,
often better integrated with HTTP than SOAP-based services are, do not require XML messages
or WSDL service–API definitions.
Project Jersey is the production-ready reference implementation for the JAX-RS specification.
Jersey implements support for the annotations defined in the JAX-RS specification, making it
easy for developers to build RESTful web services with Java and the Java Virtual Machine
(JVM).
Types of Web Services
Because RESTful web services use existing well-known W3C and Internet Engineering Task
Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that
allows services to be built with minimal tooling, developing RESTful web services is inexpensive
and thus has a very low barrier for adoption. You can use a development tool such as NetBeans
IDE to further reduce the complexity of developing RESTful web services.
A RESTful design may be appropriate when the following conditions are met.
■ The web services are completely stateless. A good test is to consider whether the interaction
can survive a restart of the server.
■ A caching infrastructure can be leveraged for performance. If the data that the web service
returns is not dynamically generated and can be cached, the caching infrastructure that web
servers and other intermediaries inherently provide can be leveraged to improve
performance. However, the developer must take care because such caches are limited to the
HTTP GET method for most servers.
■ The service producer and service consumer have a mutual understanding of the context and
content being passed along. Because there is no formal way to describe the web services
interface, both parties must agree out of band on the schemas that describe the data being
exchanged and on ways to process it meaningfully. In the real world, most commercial
applications that expose services as RESTful implementations also distribute so-called
value-added toolkits that describe the interfaces to developers in popular programming
languages.
■ Bandwidth is particularly important and needs to be limited. REST is particularly useful for
limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers
and additional layers of SOAP elements on the XML payload must be restricted.
■ Web service delivery or aggregation into existing web sites can be enabled easily with a
RESTful style. Developers can use such technologies as JAX-RS and Asynchronous
JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume
the services in their web applications. Rather than starting from scratch, services can be
exposed with XML and consumed by HTML pages without significantly refactoring the
existing web site architecture. Existing developers will be more productive because they are
adding to something they are already familiar with rather than having to start from scratch
with new technology.
Deciding Which Type of Web Service to Use
Basically, you would want to use RESTful web services for integration over the web and use big
web services in enterprise application integration scenarios that have advanced quality of
service (QoS) requirements.
■ WebServices: addresses advanced QoS requirements commonly occurring in enterprise
computing. [..]
■ RESTfull: makes it easier to write web applications that apply some or all of the constraints of the REST style to induce desirable properties in the application, such as loose coupling
(evolving the server is easier without breaking existing clients), scalability (start small and
grow), and architectural simplicity (use off-the-shelf components, such as proxies or HTTP
routers). You would choose to use JAX-RS for your web application because it is easier for
many types of clients to consume RESTful web services while enabling the server side to
evolve and scale. Clients can choose to consume some or all aspects of the service and mash
it up with other web-based services.