Is developping an EJB application is considered like a web services ?
Or the two are different ?
Or you can make EJBs like web services ?
My answer would be yes and no.
No in the sense that EJB is a programming model. This programming model contains concepts such as security, transaction demarcation, state management and persistency (stateful or stateless beans), and more. While web service is more a remoting technology, that is, a way to connect systems, which is SOAP in the case of web service. Under this perspective both are completely different topic (Web service could be compared to RMI-IIOP though).
Yes in the sense that both are usually referred as technologies to expose a service to the outside (as long as it's stateless). Under this perspective they belong to the same category. And an EJB can indeed be exposed very easily as a web service by annotating the bean accordingly.
Hope it brings some light to the distinction.
An EJB is an object that has some useful methods, typically Business Logic, and those methods can be invoked by clients in a number of ways - one of those ways can be a Web Service interface.
In development terms it's pretty much just a matter of annotating the EJB with your chosen interfaces style.
Putting the logic in an EJB can be a good idea because you get easy control over Transactional behaviour, declarative Security and scalability from the EJB container.
Related
I have been asked about the difference between Web API and RESTful services and that is also an interesting question to me. From my point of view, the only possible difference between RESTful service and Web API can be considered as that RESTful services are inherently meant to be stateless (although we can use cookies), while the concept of being inherently stateless does not apply to Web APIs as we can use sessions (can't be used in RESTful service).
However, I decided to post this question to see if there are any other potential differences that distinguish these two technologies from one another.
You're comparing a programming framework and a design paradigm. That's not a fair comparison.
Web API is a web service application framework. You can implement a REST API using it, but you don't have to. You can also write RPC-style services in it, or really just any kind of application that talks HTTP but doesn't (strictly) adhere to the REST principles.
REST is just an architectural style. It's not any protocol or framework. You can implement RESTful services using many frameworks and programming languages. Web API is just one of them for .NET.
It's true that RESTful services are stateless.
Here is the list of main REST constraints:
Client-Server
Stateless
Cache
Uniform interface
Layered system
Code-On-Demand
For more details about REST architecture I recommend Roy Fielding's publications under this link.
Coming back to your doubts, you can implement RESTful service with Web API framework, but only if you follow the rules of REST architectural style.
While implementing REST web services, is it possible to use SOA concepts?
I don't quite understand the nature of your question but it is actually the other way around because SOA is more a design pattern that evolves around breaking down modules of a system into its own independent service, where service could (or could not) be a REST web service. If that is your question, then yes, an SOA system can use REST web services.
Having a bunch of web services or rest services or COrba services does not make it SOA. SOA is a architectural design pattern that can be applied regardless of the technology used. Like Leo said it is a design pattern
SOA is a software design paradigm. Its a high level concept for designing a software . A design paradigm or pattern is a collection of best practices that are used by many programmer over the years and make them as a standard.
While REST is an architectural design pattern that is used to defined or orchestrate a web application.
Now for designing a SOA you can use any of underlying technology i.e REST or SOAP. Both are different in nature and architecture wise. Any IT organization uses SOA for exposing its business process as a business services that are well orchestrated as IT services over IT infrastructure. All these business services are loosely coupled , platform independent and interoperable. So just to wrap up all SOA is a software design paradigm that is used to orchestrate the business services and these business services are loosely coupled and interoperable. To implements SOA and your business services you can use any architectural pattern or technology like REST or SOAP.
Question should be reversed:
Can we use RESTful web services in SOA architecture
To which the answer is yes you can.
However, I assume you actually mean
Can we use RESTful web services in SOA architecture, as the primary
means of communication between services.
Some (myself included) would argue that services consuming REST on other services for anything other than POST operations violate the second tenet of SOA which states that Services are autonomous.
I currently develop a Web application that can be accessed over HTTP by an Android application or a Web browser. Both user agents basically provide the same functionalities. The Android app calls RESTful Web Services built with JAX-RS/Jersey, while Web pages are Facelets backed by JSF managed beans. I thus consider that there are two types of possible entry points to the Web app. The Web services do all the necessary work (accessing the resources, performing the database operations within DAOs, etc.) and most importantly, they must act on their own. Therefore, they constitute an independent layer.
In order to reuse the code, is it a good practice to call a Web service from a managed bean? Are their life cycle compatible?
The idea is to inject the Resource object into the managed bean (with CDI, but not necessarily) and to call its methods programmatically. The Web service would act as a business delegate (?) to the underlying services.
I widely googled the question but I didn't get a clear answer. I saw some pieces of code where the managed bean invokes a Web service with its URL, but since all my components are located in a single server app, I don't see what prevents me from linking them directly.
Subsidiary question on error handling: I am also annoyed with the idea of catching WebApplicationExceptions from the Web service into my managed bean for returning error messages back to the view (with FacesMessage). My father always told me that I should never catch runtime exceptions...So, is there a good way to handle them correctly?
In this case, you would be better off having the business logic out from the Web Service into "some central shared code". Then, then web services and the managed beans would call into the shared code.
I've put the term "some central shared code" in quotes, as what you use depends on your runtime environment. If you're using a JavaEE container like Glassfish or JBoss, this sounds like a perfect use of EJB and stateless session beans (which are designed to ensure the resources are managed well). You could also use Spring Beans as the shared code and centralize the logic that way.
It all depends on what you find more comfortable from a development and production sense. But both support injection, so both the Web Service and JSF Managed Beans could have the services injected as any other resource.
Spring Framework provides many technologies for applications to communicate with each other over HTTP.
HTTP Invoker
RESTful MVC Controller
JAX-WS
Spring-WS
What are the differences among them? What criteria dictate which one to choose?
JAX-WS is a standard maintained by the JCP (Java Community Process) and every full featured application server implements it (or, at least, provides an implementation for it). It's easy to use (you just need a few annotations in your service class endpoint) and you don't need to worry about the implementation (and your application will carry less dependencies within it).
Spring-WS was widespread when JAX-WS was a work-in-progress (or didn't ever existed). It achieves the same that JAX-WS but it's a bit more cumbersome. From my experience it's loosing adepts in the benefit of the latter.
HTTP based services (as HTTP invoker and REST) claim to be a bit more lightweight than JAX-WS (because the endpoints don't need to handle the SOAP envelope) but are not as strong-typed as WSDL based ones.
When I have to choose I usually decide for JAX-WS if there is not a strong reason for the REST based approach. I don't like at all the HTTP Invoker one because it's security issues (even though when talking about intranets), but I think this is a kind of personal choice.
If you are integrating your own apps and you have tight control over application client and wire (e.g.corporate intranet) then use HTTP Invoker - it's really transparent to application and easy to setup. Http invoker over Internet with non reliable client authentication (without PKI auth) may be not good idea, there are security problems with java serialization used in invoker.
If invoker doesn't suit you well, and it's your own apps - then consider REST.
I think WSDL based services are good for external integration - you can define protocol with strict rules.
I was having a discussion with a colleague about Web Services. Now we both agree that a Web Method should only have one responsibility, as per single responsibility principle, but what about the entire service? I always considered the Web Service as a gateway, his argument was that if the web service has methods that have a different area functionally or from a domain perspective then those methods should be housed in a completely separate web service. I'm looking to see what the community has to say on the matter.
Should a web service with functionally different methods be housed in different services and URLs?
OR
Should a web service that's considered an internal gateway house methods that are functionally different but related by the gateway concept?
I think that this will be a matter of opinion, but we chose to structure our web services using the same guidelines as used for class libraries in C# (Since we're a .NET shop). Similar funcitonality goes into similar web services, named to clearly define what to expect in each web service.
RetailLocationServices
EmployeeInformationServices
FinancialServices
etc
How about a model that consits of one url and then functional areas:
http://api.<yourdomain>/1.0/Finance/
http://api.<yourdomain>/1.0/Users/
http://api.<yourdomain>/1.0/<FunctionalArea>/
You could omit the version directory if needed.
In my experience with working API's at some point you'll want/need to roll out another version. Some people do this with query string params, I prefer it in the url for visibility to the caller.
You could then vertically slice the development of your services, therefore upgrades to one won't affect the others. Some auto-build-magic could then help you deploy them too.