Could somebody explain SOA, Microservices, REST and Web Services in simple terms. It is really fascinating and confusing me. Any help would be appreciated.
SOA (Service oriented architecture) as the name suggests that it is combination of services. These services are loosly coupled and interacts with each
other to provide a solution. Services may be RESTful web service to carry out some function.
Microservices - Again as the name suggests micro services. The idea behind microservices is that it becomes easier to build and maintain some type of services when they are broken down into smaller, composable pieces that work together.
Webservices - A service (some functionality like checking seat availability in a train) available on web is known as web service. Such services communicate over the WWW using HTTP.
REST - It is just an architectural style for designing webservices.
We can think like this:- SOA is having some services. These services are combination of microservices. Those microservices are exposed as webservices and the webservices are build on REST.
SOA
Building software out of widgets.
Microservices
Building software out of small widgets.
Web Services
Makes widgets look like the internet
REST
Makes widgets look a lot like the internet
Related
Right now I'm working in WebApi (trainee developer), and have good knowledge in webapi . But , I don't know anything about WebServices.
My Questions are :
1.What is WebServices?
2.What is the Use of WebServices?
3.Instead of WebServices why we are using WebApi.
4.Where we can use WebServices?
5.At a time We Can use both Webservices and WebApis?
Exposing the Existing Function on the network
A web service is a unit of managed code that can be remotely invoked using HTTP. That is, it can be activated using HTTP requests. Web services allow you to expose the functionality of your existing code over the network. Once it is exposed on the network, other applications can use the functionality of your program.
Interoperability
Web services allow various applications to talk to each other and share data and services among themselves. Other applications can also use the web services. For example, a VB or .NET application can talk to Java web services and vice versa. Web services are used to make the application platform and technology independent.
Standardized Protocol
Web services use standardized industry standard protocol for the communication. All the four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack. This standardization of protocol stack gives the business many advantages such as a wide range of choices, reduction in the cost due to competition, and increase in the quality.
Low Cost Communication
Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services. This solution is much less costly compared to proprietary solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented on other reliable transport mechanisms like FTP
For Example in Asp.Net Core : https://dzone.com/articles/step-by-step-aspnet-core-restful-web-service-devel
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.
What does a Web service really mean ? I am not looking for a theoretical explanation, I am looking for something practical.
I was thinking that anything I can call from an external client is a Web service, so a basic PHP which returns JSON data could be a Web service.
But then I started reading about Web services in W3Schools.org and I got confused. If the PHP URL which returns JSON data is a web service, why would I need to do SOAP, WDSL etc ... to create a Web service. Isn't it extra work?
Also, if SOAP is the way data is sent back and forth, what about other transport types?
What differentiates a RESTful Web service from a SOAP based web service?
When you are talking about a webservice people generally misunderstand what it means, a webservice is simply a way to interact between a and b that abstracts the use of local technology standards. A WSDL defines the way in which the SOAP message is being sent over the channel. REST uses JSON over HTTP, WSDL uses SOAP over HTTP.
The advantage of a webservice is, say you develop one piece of code in .net and you wish to use JAVA to consume this code. You can interact directly with the abstracted layer and are unaware of what technology was used to develop the code.
SOA is a set of design paradigms and standards that tell you how to develop your services, in SOA each service is meant to comply with the principles listed below. WSDL is generally linked with but not essential for a SOA solution. If you wish to learn about SOA google "Thomas Erl SOA".
Priciples of SOA
Standardized service contract
Service loose coupling
Service abstraction
Service reusability
Service autonomy
Service statelessness
Service discoverability
Service composability
This Q&A Restful vs Other Web Services brings a lot of light to what is a webserver, and differences from SOAP and REST. Id recommend to read all the answers (many of them are very good).
I want to understand some points :
Does using- SOA mean that I am using web services ? (or vice-verse?)
If I use web services with CXF, do I need an ESB ? what are the advantages of ESB like MULE in an architecture with web services ?
if I publish my web services in Java, does that means any client who has my WSDL can use my service, even if he/she uses .NET or something else than Java? Can ESB handle that?
Does using- SOA mean that I am using web services ? (or vice-verse?)
- SOA is a concept and web service is an implementation of SOA. There can be many ways to implement it but the most common one is the web services.
If I use web services with CXF, do I need an ESB ? what are the advantages of ESB like MULE in an architecture with web services ?
ESB is a major component in you SOA. Its the main integration hub.
Following diagram will give you a more understanding about SOA and ESB. (Disclaimer : I work for WSO2 and this is one of the diagram that gives you a clear understanding about SOA and ESB)
http://4.bp.blogspot.com/_yO8q3CIhuZs/S-Zq88vkJlI/AAAAAAAAAak/QAJeDVXVL_4/s1600/wso1.png
if I publish my web services in Java, does that means any client who has my WSDL can use my service, even if he/she uses .NET or something else than Java? Can ESB handle that?
If you are talking about web services, that means they are independent from programming language. Of course ESB can handle it and it can handle many other protocols as it is the integration hub.
Unfortunately, only the use of a specific technology is not a concrete evidence that you are doing SOA, as said in other response by Kasun Indrasiri, SOA is a concept, a technique that can be implemented using various tools from different vendors.
If you are designing services following the SOA Principles, you will be probably doing SOA, even if the tools you are using do not have all the features present in other modern platforms.
In my opinion, if your company does not have a of multi million dollars budget to spend on software licenses, you can still benefit from SOA using current tools.
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.