I am confused about the Transactional Support in Web service
is its the execution of different pieces together
or its the Status Code after the Execution is been done
in other words I wanted to know how transactional support is provided in Web Services technology
Related
I need to deploy multiple web jobs for my current project. However, none of them will be too resource intensive, so I will be using the same App service plan. I am trying to decide between
Create separate App Services per Web Job and deploy them all into the same App Service Plan OR
Create a single App service, and deploy multiple instances of the Web Job into that same app service, with different web job names to make them unique
I know this answer may be based on different opinions, but I am hoping you could share some things to consider. For e.g., one advantage of #1 is that it is easier for me to deploy each web job separately in that option. Any other things that I should consider?
Thanks!
#Snooks, Web Apps are designed to run multiple Web Jobs and there is no platform limit (although there might be practical limits depending on what your web job is doing). My suggestion would be to go with route 1 from a management perspective. This will make life easier when navigating through the portal etc.
A third option to consider as well would be Azure Functions (serverless). While many customers create app services that aren't hosting any web site just to use for the web job capability, the initial intention was for app services services to serve web sites and then also have automation capability via web jobs.
Since web jobs became so popular, Azure Functions was born to provide a more focused product on task/job automation (and much more) while running on a serverless platform. This means you only pay for what you consume, whereas with a web app, you pay a flat rate each month, no matter how much or how little you consume.
If your requirements state you must go the route of Web Jobs, I would certainly go with route 1 just to avoid having to manage multiple apps. If you are willing, I think it's worth looking into Azure Functions to see if it meets your needs.
is it possible to achieve transactionality using web services that are implemented in different technologies?
For example: let's imagine a case where we want to offer an integrated service of 2 different organizations, each of which already have their different systems implemented using different technologies and located in different countries.
Organization A has a Java server exposing Rest services that allow consumers to insert data in a table, then Organization B has a .Net server exposing Rest services that also allow consumers to insert data in a table.
Then I want to create a new server to integrate both these services in one, allowing consumers to insert in both organization's databases. So from this new server I have to invoke those 2 rest services in a transactional way (meaning that both organizations will insert or none will insert if there is a failure, it will rollback).
Is that possible to achieve even tho server 1 and server 2 are implemented with different technologies? What if there were n servers all implemented in different technologies and all exposing Rest services?
It is not possible to have real transactions in case of microservice architecture. You have to implement compensations which roll back changes in case of failures. See Saga pattern for one of the approaches.
Look at the Cadence Workflow that makes implementing Sagas trivial. Here is an example.
The closest I got to finding the actual difference is this article.
But I didn't understand what would make me choose one over the other and if microservices can also use a REST API and communicate via http.
I mainly didn't understand what a microservice is and if it can come instead of a webservice, other than the purpose of
breaking large software applications into loosely coupled modules
A microservice is a software architecture, which can be implemented with webservices.
A webservice is just a technology (one of many) for providing services over "web" or HTTP.
The main point is: a web service is (as the name announces) something that you would expect to "deal" with HTTP - in other words it does something in the context of the world wide web.
Whereas a microservice is not subject to the WWW context. At its core a microservice is supposed to provide one specific service - but there is no restriction to the http protocol for example.
Often a microservice implements a restful "web service" - but it doesn't have to be that way!
Beyond that, microservices are often meant as counter model to a huge monolithic application that serves many different kind of requests.
I got simple answer here that says :
Microservices is a new software architecture. It is based on web services. But it can be any service implemented as an independent feature that has its own database and can be deployed independently.
Microservices is an architecture wherein all the components of the system are put into individual components, which can be built, deployed, and scaled individually.
Microservices are the extension of web services.
Web services are typically vertical in nature(Provider-Consumer communication) whereas microservices are horizontal in nature
Microservices are seen as architecture due to the following.
microservices have belonged to one specific application.
microservices are addressing specific concern so that can be said as lightweight.
Changes are isolated in nature because the change in one microservice doesn't affect other (Ex. Changes done in login microservice does not affect the payment microservice)
Scaling individual microservices are easy.
Microservice usually has its own database.
Microservices : -
Microservice is a software architecture that can be used alongside web services. This method involves the splitting of large software applications into decoupled modules where microservices run unique processes and communicate through APIs. Its development can be through the use of either messaging, event-driven APIs, or using non-HTTP backed RPC mechanisms.
Microservices architecture saves the day when large applications fail or are down. If a particular service fails in communication, the overall application cannot be affected by the failure of a single module. The combination of microservices in Java, C#, Python, and mobile software development languages is possible. It can be independently deployed in service models for a business domain.
Web Services :-
A web service is just one of several technologies that can provide services over “web” or HTTP. As a specific type of service-oriented architecture (SOA), web services represent a web application’s functionality.
It defines a mechanisms interaction between an API and the main code by using standard HTTP protocol and universal formats of data representation such as XML, JSON, and so on. This allows software applications developed by different technologies to communicate with each other.
Web services are not involved with frontend development. They are not connected to any development languages or user device software platforms. The combination of different web services into a single one is also possible if written in different languages and for separate operating systems, just like in microservices.
Microservice is a subset of web services. Also used to name Architectures like "Architecture based on microservices"
Microservice is an artifact, not an architecture. Several world class companies know that
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html
Before the microservice artifact, we had the classic web service or rest api. Even before this we had the Soap web services with XML.
So, as a summary when someone talk about microservice, he means a subset of web service with some characteristics that differentiate it from classic web services or rest api.
One main characteristic is a unique database or Database per Service
Here another characteristics from the goods like AWS. Some of them apply to rest apis or soap services. I will mark with bold some very specific for microservices.
https://aws.amazon.com/microservices/
Agility
Flexible Scaling
Easy Deployment
Technological Freedom
Reusable Code
Resilience
https://microservices.io/
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
https://www.baeldung.com/cs/microservices-db-design
Database per Service
CQRS
https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
Microservice is a piece of autonomous application that performs for a larger application architecture.
Web service is an approach to make the application available to other applications by web ui.
As per Service-Oriented Architecture (SOA) definition, an architectural style that supports service-orientation.
Does that mean only web services (SOAP and REST) are treated as part/backbone of SOA? What about messaging services?
No and yes.
A webservice can be designed in a service orientated way, but a "service" (SOA) describes functionality, a bundle of business logic.
Service orientated architecture means, you have different systems, different users, and the way you implement your business focuses on the whole beeing a service.
The former (SOA) is something abstract, a paradigm, a commitment on how to implement something, the latter is technology (REST, SOAP, ...).
In conjunction with webservices, the "how to" is often described using WS-Business Process Execution Language (short: BPEL). It is used to orchestrate providers and consumers and allows high-traffic processes to scale in the cloud.
Consider your bank, processing many business steps per second in a very standardized fashion; using standard services like transfering money from one account to another.
Talking about Java and JMS, Oracle has a tutorial up: This example shows the steps to create a simple JMS queue in WebLogic Server 11g for testing purposes.
What exactly is web service composition?
Composition refers to the way something is build, the new term at the moment is mash-up which basically means utilising a variety of different services in a composite application. So that functionality of disparate application can be used in one application.
I think your referring to service granularity - which means how much functionality a service exposes. a coarse grained service will expose a whole process as a consumable unit whereas a fine grained service will expose a specific unit of logic from a larger process. Obviously, it is up to the service architects to determine what granularity of service works best in the given environment.
This also, in a way has to do with the style of SOAP message you are using whether it is RPC style or document and that a service should be atomic and not hold external state. Meaning it does not need to know any more information other than that in the SOAP message to perform its function.
Hope this gives you a good starting point. The trouble with service-orientation is that it differs depending on who you read, but the main points stay the same!
Jon
Some web services which are provided for clients are abstract and composition of some smaller web services and it's called web service composition.
Sometimes there are more than one web service in order to use as the mentioned small web services, so we choose them based on QoS (Quality of Service) and many researches have been done on this subject.
Web service composition involves integration of two or more web service to achieve more added value of business functionality. A work flow composer is responsible of aggregating different web services to act as a single service according to functional requirements as well as QoS constrains. BPEL is one of the popular composers uses XML language to perform service composition. Fine-grained services perform single business task and provides higher flexibility and reusability. However, coarse-grained service involves performing complex business functionality leading to lower flexibility