I've been trying to get my head around some SOA principles and I came across this page which describes a microservice in SOA:
http://soapatterns.org/design_patterns/micro_task_abstraction
Solution: Individual units of non-agnostic logic with specialized
processing and deployment requirements are separated using the
microservice model and abstracted into a microservice layer in which
there is the architectural freedom to tailor environments in support
of specialized service processing and deployment requirements.
What are exactly these specialized processing and deployment requirements?
And what's the key difference between a microservice and a taskservice in SOA? as they both appear to me none-agnostic and can be composited of other entity and utility services.
Service Oriented Achitecture (SOA) deals with defining services, design of what the services are meant to do, their interface, governance, service lifecycle, operational SLA's and "usage agreements" (these last two lead to a number of non-functional requirements), among others.
Microservices can be considered more of a development and deployment approach. If SOA is defined correctly (your interfaces are clean, designed with appropriate granularity, loosely coupled), it is easier for you to apply a microservices approach, subject to your technical platform.
Once you have defined a service, your implementation considerations would include infrastructure, application servers, build and deployment mechanisms. A key defining feature of a microservice deployment model is that as much of the "stack" is self-contained within a single deployable unit (can be referred to as a container).
Using a Java example, at the very least a microservice might be one service or function (exposed as Rest or SOAP) running in its own standalone JVM (bundled libraries, application/web server) which you can refer to as a container (example here). Contrast this with a more "traditional" approach where you might have one team managing the application server on which you might deploy multiple services or functions. The major benefit is you can avoid conflicting dependencies, your environment is fully in your control (effectively a few lines of code) and your service might perform more predictably as it has no interference from other services contending for the same resources (JVM threads, Data sources to name a few).
Specialised container management tools such as docker and associated scripting allow you to put together any required configuration you need from your environment.
Update 16/Jan/2018
Also note this paragraph on the distinction between SOA and Microservices as concepts. I translate it as: People didn't do SOA right so needed a new buzzword. True to an extent. However, you could also see the two as complementary concepts - SOA being more design heavy while microservices being a more deployment focused methodology.
Related
My company has a .NET project which serves following use cases
It listens on a WebSocket Port with certificate based client authentication.
It listens on another WebSocket Port with authorization header based client authentication.
It listens on a TCP Port with certificate based client authentication.
On the above three ports different set of client devices are connected.
Now my company wants to convert this application in .NET Core so that this can be deployed on Linux servers to save the deployment cost. As an architect I am thinking in the direction of adopting microservices architecture along with migrating the application in .NET Core. So I am thinking that the above application can be break down into three microservices based on the above use cases.
AFAIK microservices architecture means breaking down your application into smaller services which serves a particular use case. So breaking this complete application into three different microservices is correct or not.
My organization is very new to micro services architecture.I just want to know that whether this thinking is correct or not as per architecture.
Thanks in advance for your help.
Generally I'd try to break things down based on business domains (or business capabilities) instead of technical reasons.
A good place to start might be reading about domain driven design and bounded contexts - see here - there's some good further reading at the end of that link.
Yes you are thinking in right direction.
Here are my suggestion-
you should go for .NET Core and Docker for implementing your Microservices in a better way.
There can be multiple cases when you will go for docker container in this scenario-
1: Run the same image in multiple containers
2: Manage different Containers
3: Run the same image in multiple environments
4: Tag and Run image with different versions
And other reason to go for micro services with docker-
Microservices are smaller in size
Microservices are easier to develop, deploy, and debug, because a fix only needs to be deployed onto the microservice with the bug, instead of across the board
Microservices can be scaled quickly and can be reused among different projects
Microservices work well with containers like Docker
Microservices are independent of each other, meaning that if one of the microservices goes down, there is little risk of the full application shutting down.
You do more research on the same and easily go for micro services architecture.
This may not be answering your question, but I thought it could be useful, especially in light of the fact that your organization is very new to micro-services.
I would recommend to carefully evaluate the advantages and especially disadvantages (complexity) that micro-services architecture introduces.
Just a few examples of things that you will need to think about are log aggregation, communication between services (sync vs async), E2E and integration tests, eventual consistency, etc. Obviously you may end up not having to deal with some of these, but all of them do become a lot more complicated with micro-services.
There should be good business justification to take on the additional complexity (=cost).
Microservices shouldn't be measured on how small enough but how autonomous and independent they are. Microservices are great to be designed around business and domain context and mentioned in details Identifying domain boundires
Since you are starting to build microservices in .Net core why not consider severless microservices ? You have plenty on options in major clouds (AWS,Azure) to build serverless microservices. Serverless are quicker to build and you get generous free tier and you don't have to manage clusters. Is there specific reason you would want to use Kubernetes? you can read more about cloud native and servlerss here Design Cloud native and Serverless
Is it advicible to build the MSA based services on Oracle SOA or any other ESB suite for that matter? Is there any advantage or disadvantage?
If I am using Java, Spring and JPA over a message queue - say - RabbitMQ, I can achieve it in a more controlled environment with less recurring expenses. Of course will end up mixing tools like Drools or JBPM or similar to achieve things that may be OOTB (Out of the box) in the SOA Or ESB Suite. But scaling a specific service without paying licence fee for an additional environment should certainly be a good catch right?
Microservices architecture pattern applies to development of backend systems/services, whereas ESB (e.g. Oracle SOA Suite) is intended as an intermediary layer between consumers and backend services. Backend services contain rich application logic, whereas ESB services provide only intermediary functions like routing, transformation, orchestration etc.
ESB is not intended for rich application logic, though it's possible to do that.
Using ESB (e.g. Oracle SOA Suite) to host microservices is achievable, but you will get a big overhead comparing to limited functions and scalability. If you are looking for centralized API management (tracing, security etc.), you can put an API gateway into your architecture instead of full scale ESB.
Can we safely say that if ESB provides Orchestration features, it is eligible to be an implementation of BPM?
I understand that BPM has a different purpose, which is to Model some business processes and the implementation of those business processes can be done by any simple Java/J2EE application, complex SOA application, or some application saying that I provide BPM. Is that right?
First Question:
Your statement is valid for some business processes which merely models request-response interaction.
But when it comes to complex business processes we need to consider some other features apart from orchestration features. Here I have list down few such scenarios.
Let's take a business process which requires to maintain its state for a long period of time. We normally call them state-ful or long running business processes. To support these sort of business processes, there should be a state persistence mechanism. This functionality is not relevant to orchestration features.
Consider a business process, which requires some compensation capabilities. In that case, some of the business process modelling standards like, WS-BPEL have defined its compensation mechanisms. So apart from orchestration features, there are some other features which are needed to be considered.
Second Question:
Yes. But there are several pros in a BPM engine compared to your mentioned implementation mechanisms.
One advantage is, it's not possible to achieve a level of modelling abstraction provided by a BPM engine from a Java application. Let's say we used a JAVA application to implement a business process logic and that business process went to production. Say we need to change a endpoint URL of its partner service. In this case, now the business process implementation need to be modified, re-compiled and deployed back into the production system. if we implement the business process with a business process language standard like WS-BPEL, we can change the business process configuration very easily and push it back to the production. This improves the efficiency and reduce the business maintenance cost.
As well there are other reasons like easy adaptability and flexibility.
I've created these slides some time ago to explains exactly how you can use them both and the relationships between them:
http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers
You need to understand the different perspective between something like BPEL/ESB/Orchestration and BPMN (business oriented) they have very different scopes.
Cheers
Normally ESB is assigned to the middle layer — orchestrating low-level services into larger service units, which will be exposed to the business for use in processes — and BPMs in the top layer.
So BPM will be used in the Business Process Orchestration Layer and ESB will enable and facilitate this by working in the Business Services and Service Enablement.
In another words to be successful with business processes first you need to have all your systems and apps exposed as services; that is where an ESB comes into play.
You could see this link : http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/
Let me add clarity by making the distinction between BPM, Orchestration, and ESB, via design patterns and specifications.
Generally speaking, "Orchestration" has been defined as a compound pattern employing the Process Abstraction, Process Centralization, and the State Repository design patterns. By virtue of the implementation of the State Repository Pattern and contrary to a previous post, Orchestration supports long running, synchronous business processes, just like BPM.
The major practical distinction between the 2 is that Orchestration middleware (e.g. WebSphere Process Server, BizTalk, Oracle BPEL Manager, and Windows Workflow Foundation) supports most of the WS * specifications. This includes Ws BPEL, Ws Security, Ws Atomic Transaction, Ws Business Activity, Ws Reliable Messaging, etc., while most BPM Tools do not.
As a result, feel free to use Orchestration at an Enterprise Level, but be very careful about using BPM in that scope.
In practice, both BPM and Orchestration tools enable the graphical representation of a business process. The distinction is that Orchestration may be expressed through Vendor-Neutral BPEL (Business Process Execution Language), while BPM is expressed via Vendor Specific BPMN (Business Process Modeling Notation). This is another reason to avoid BPM tools at the SOA/Enterprise Level.
In cases where a BPM Tool implements the Ws * specifications, it is an Orchestration Engine for all practical purposes. The distinction again being that BPM tools rely on Vendor-Specific BPMN and Orchestration tools rely on Vendor-Neutral BPEL.
In cases where both BPM and Orchestration need to coexist, limit BPM to application architecture (e.g. MVC style) and let Orchestration promote the sharing of enterprise assets.
An ESB is an entirely different animal. It should used for asynchronous, rather than synchronous processes and relies on a different set of design patterns (i.e. Service Broker, Asynchronous Queuing, Intermediate Routing, and the Content Enricher patterns)
What are the differences between service orchestration and service choreography from an intra-organization point of view.
Basic technologies (such as XML, SOAP, WSDL) provide means to describe, locate, and invoke services as an entity in its own right. However, these technologies do not give a rich behavioral detail about the role of the service in more complex collaboration. This collaboration includes a sequence of activities and relationships between activities, which build the business process. There are two ways to build this process: service orchestration and service choreography.
Service orchestration
Service orchestration represents a single centralized executable business process (the orchestrator) that coordinates the interaction among different services. The orchestrator is responsible for invoking and combining the services.
The relationship between all the participating services are described by a single endpoint (i.e., the composite service). The orchestration includes the management of transactions between individual services. Orchestration employs a centralized approach for service composition.
Service Choreography
Service choreography is a global description of the participating services, which is defined by exchange of messages, rules of interaction and agreements between two or more endpoints. Choreography employs a decentralized approach for service composition.
The choreography describes the interactions between multiple services, where as orchestration represents control from one party's perspective. This means that a choreography differs from an orchestration with respect to where the logic that controls the interactions between the services involved should reside.
Service orchestration: you put together several services by a fixed logic. This logic is described at a single place. You can imagine a team of people with a manager doing micro-management. The manager precisly tells what, when and who should do. The team members do not care of the entire goal of the job, the manager combines the outputs into a single deliverable.
A practical example is a BPEL process. BPEL process contains the logic, can invoke several services and combine their responses into a single service response.
Service choreography: the decision logic is distributed, with no centralized point. You can imagine a home, where everybody aims for the common good and works pro-actively without micro-management. Or you can imagine a human body, where different members are interdependent and work for the common goal.
A practical example is event driven processing, where an agent is activated by an event and does its job. All the agents make a system together. There is no centralized logic.
Choreography possibilities may go farther beyond orchestration as it is more aligned with the real world.
My opinion is that we do not need to distinguish much between these two, as we need to focus on the business logic. Where a single point of logic does the job, we do orchestration. Where a problem cannot be covered by a centralized logic, we are forced to choreography anyway. That is why we often come accross orchestration in IT, whereas choreograhy remains more an academical concept and a subject for research. And very often we do choreography without actualy knowing it, as in the real world.
Since the thread is old but still writing to it for those who will stumbled here in search of this question as I did. This is much debated question in Service-oriented architecture (SOA) which needs much cleaner explanation for beginners.
Orchestration: Executable Process
Used in private business processes
A central process (which can be another Web service) takes control of
the involved Web services and coordinates the execution of different
operations on the Web services involved in the operation
The involved Web services do not "know" (and do not need to know)
that they are involved in a composition process and that they are
taking part in a higher-level business process.
Only the central coordinator of the orchestration is aware of this
goal, so the orchestration is centralized with explicit definitions
of operations and the order of invocation of Web services.
Choreography: Multi-party Collaboration
Choreography, in contrast, does not rely on a central coordinator.
Rather, each Web service involved in the choreography knows exactly
when to execute its operations and with whom to interact.
Choreography is a collaborative effort focusing on the exchange of
messages in public business processes.
All participants in the choreography need to be aware of the business
process, operations to execute, messages to exchange, and the timing
of message exchanges.
Choreography vs. Orchestration
From the perspective of composing Web services to execute business
processes, orchestration is a more flexible paradigm and has the
following advantages over choreography:
The coordination of component processes is centrally managed by a
known coordinator.
Web services can be incorporated without their being aware that they
are taking part in a larger business process.
Alternative scenarios can be put in place in case faults occur.
Services can be distinguished between atomic services and services composed of other services. Such compositions are called "orchestration". Sometimes workflow, sometimes business process. For instance, BPEL is an orchestration language, but calls itself "business process execution language".
There is no requirement that services need to be hierarchically composed. That means, two services may talk to each other. The protocol running between them is called "choreography". It may be two services, but usually, there are more than two services involved. Each service in a choreography may be seen as orchestrator of the partner services. Each service taking part in a choreography may be realized as orchestration/workflow/process.
An orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.
A good scientific article distinguishing choreography, interface behavior, provider behavior, and orchestration is the following one:
Dijkman, R. & Dumas, M. Service-oriented Design: A Multi-viewpoint Approach International Journal of Cooperative Information Systems, 2004, 13, 337-368
Andrei and others did a good job explaining what is orchestration and what is choreography. For the software architect choosing between these two alternatives, it is also important to compare them with respect to different qualities.
Orchestration pluses over choreography
Reliability: Orchestration platforms have built-in support for error handling and transaction management (compensating transactions). In choreography, custom-developed workflow and error handling tends to be more error-prone. Also, choreography is often event-driven and much of the processing is asynchronous. Therefore, choreography may require undo/correction events that add complexity to the solution.
Modifiability: Creating and changing process workflows and complex service compositions is easier in the visual BPM tools found in orchestration platforms. You gain in "process visibility".
Choreography pluses over orchestration
Performance: Orchestration incurs a performance overhead due to workflow script interpretation and the additional layer of the orchestration platform itself.
Cost: Choreography does not require additional middleware or language, which have associated learning curves and governance burden.
EDIT
An orchestration solution might introduce a SPOF if the orchestrator element doesn't employ a mechanism for high availability. Thanks #Deepak por pointing this out in a comment.
Orchestration is useful when you have control over all the actors in a process - when they're all in one domain of control and you can dictate the flow of activities. This is of course most often when you're specifying a business process that will be enacted inside one organisation that you have control over.
Choreography is a way of specifying how two or more parties - none of which has any control over the other parties' processes, or perhaps any visibility of those processes - can coordinate their activities and processes to share information and value. Use choreography when coordination across domains of control/visibility is required. You can think of choreography, in a simple scenario, as like a network protocol. It dictates acceptable patterns of requests and responses between parties.
Another way to look at Service Orchestration vs. Choreography:
- Service Orchestration: Around a Business Domain.
- Service Choreography: Among multiple Business Domains.
I'd say choreography is well suited internally for highly decentralized organizations. You won't need a central business process executor. This facilitates independent growth and development by each of organization sub-units.
(I subscribe to this interpretation of orchestration vs. choreography question:
http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)
One can use both choreography and orchestration is the same system as we have done in our product. Various actors performing various tasks dispatched to them are choreographed by the event pub/sub system via events they generate. For example, when a prime mover carrying a container arrives at a warehouse, that event, which is subscribed by the warehouse manager app, prompts the warehouse manager to activate the resources to unload the cargo.
But when exceptions happen, such as the forklift to carry the load breaks down, that event starts an orchestration engine (a workflow processor) to orchestrate the task for various actors as per the exception handling workflow to handle the exception.
In orchestration, there is a conductor and there are instrument players. Players play according to how conductor conducts. If conductor is replaced, the harmonic expression will be different i.e. it is still the same play (service) but with a different outcome. For example, to provide a financial arrangement proposal, the orchestration service will conduct by asking (invoking) each player (entity or utility service, e.g. credit check) to play (return results or adjust/update its playing) according to conductor's template (business rules).
In choreography, there is a choreographer and there are groups of dancers. Choreography is a direction, but each group of dancers is autonomous in how to realize that direction.
Both orchestration and choreography are two philosophies of process formalism at large scale, i.e. collaboration spaces. A collaboration space is a formal representation for an industry, for example health industry, food industry, automotive industry or ... . So you should have some service providers at small scale able to speak some language of communication before you decide to orchestrate them or use choreography to supply some demand meaningful to end-consumer.
Orchestration typically follows what has been famous as middleware in distributed systems. Some good tooling examples within IT industry can be Juju, Zapier IFTTT. You have centralized control, auditory, modification and trouble shooting over services you consume.
Choreography is more decentralized than orchestration in the sense that it accepts more autonomous collaborators. For example bitcoin network is a collection of service providers called nodes which collectively provide a Defi service namely distributed ledger functionality to its service end-consumers. But this does not have any centralized authority in charge, and there is no total-view over whole network. There is just a consensus machanism that if respected candidate service provider joins the network and participate in end-consumer service provision. Anywhere you need to attack trusted third party and its side effects such as corruption, an orchestration would not suffice.
Again any collaboration among actors in any industry can be subjected to orchestration or choreography, so I hope limiting examples only to IT industry is not misleading.
Also I can add, naming suggests analogy between the two and stage performance. In an orchestra, every instrument player is harmonized with other team members if he/she follows the single conductor. On the other hand analogous to stage dancing in choreography there is no conductor, each stage dancer only harmonize himself/herself with his/her partner (better if spoke as peer), with no single point of harmonization leadership. But still both present harmonization to viewers.
my plan is to develop or use a Java-based integration framework (ESB, SOA whatever) that deals with services, with the following constraints:
a Service can be deployed on multiple machines but doesn't have to be present on every one of them
a Service can be deployed and re-deployed (with a newer version) separately
a Service is connected to other services either by:
in-memory connections
(async / sync) remoting to other machines
the routing logic of the Service connections should be configurable on the fly, without re-deploying or restarting anything
I know that OpenESB is close to these requirements, however it requires redeployment of the service to change the routing (suppose the connections are HTTP BC based), but I'm unfamiliar in this regard with MuleESB, WSO2, JBossESB, whatever open source ESB... Is there any good solution for this (e.g. configurable in-memory and/or remoting routing)? I don't really care about clustering as I plan to use the servers separately, and the designated (if required) JMS solution would be HornetQ if that matters.
You mention several different concepts, but a combination of an ESB pattern, Apache Load Balancer and Maven should get you close. Do not get to hung up on the product, settle on a paradigm/pattern and the decision of the product will be easy, it either does things the way you like or does not.
Here is the pattern I use.
SOA Design Patterns
This may also interest you SOA for executives
Cheers
After a long discussions about the pros and cons, we are going to have a HornetQ-based (JMS MQ) solution, where we create message routing rules and sometimes processing codes that handle the different kind of routing. HornetQ is able to handle the in-jvm requirement too, but that part will be covered under the hood.