Skip to main content
Bounty Ended with 25 reputation awarded by CommunityBot
added 258 characters in body
Source Link

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service ( Business logic details )
  • What you have currently ( available APIs and services )
  • What you are going to deliver for how many users ( Load estimation )

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB, BPMS, and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

Update: Check WSO2 Tutorial Videos to find a better understanding of how ESB Tools provides functionalities. But we cannot escape from writing codes :-)

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service ( Business logic details )
  • What you have currently ( available APIs and services )
  • What you are going to deliver for how many users ( Load estimation )

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB, BPMS, and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service ( Business logic details )
  • What you have currently ( available APIs and services )
  • What you are going to deliver for how many users ( Load estimation )

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB, BPMS, and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

Update: Check WSO2 Tutorial Videos to find a better understanding of how ESB Tools provides functionalities. But we cannot escape from writing codes :-)

added 81 characters in body
Source Link

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service ( Business logic details )
  • What you have currently ( available APIs and services )
  • What you are going to deliver for how many users ( Load estimation )

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB/BPMS, BPMS, and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service
  • What you have currently
  • What you are going to deliver for how many users

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB/BPMS and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service ( Business logic details )
  • What you have currently ( available APIs and services )
  • What you are going to deliver for how many users ( Load estimation )

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB, BPMS, and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?

Source Link

In fact, ESB and Process Designers are being used in enterprises but not for everything, and using ESB does not mean that you may no longer need to write codes.

When we talk about exposing service, the biggest questions that appear are:

  • What is the scope of that service
  • What you have currently
  • What you are going to deliver for how many users

The above questions are critical for choosing the technology and an approach for the development of a solution.

ESB/BPMS and such tools are good, they provide flexibility for implementing some integrations by their workflow engine and their built-in features like mediation, QoS, and so forth. But they cannot cover all of your requirements especially when you talk about complex businesses, somewhere you should implement your business logic. You can write 'em inside the processes by supported languages by your business process tools ( i.e: Camunda supports javascript ) or you need to integrate with your microservices/applications through HTTP APIs or Message Brokers. But for some basic processes like condition, sending emails, and executing queries, you can use the built-in connectors/processors of ESB/BPMS. But these tools are not "Fast" and "Light-weight" and if you are going to serve requests to a huge number of clients at the same time, you might provide high-spec resource clusters to handle these loads.

On the other hand, you could use microservices architecture to provide this capability to be agile enough and exactly choose the proper solution for your services. you might consider using some out of the box ready platforms for one of your services and implementing some others by GoLang or NodeJs and also your other services by .NET or Java. You can feel free to minimize the development cost and time and maximize flexibility and efficiency.

If you want to learn more about the Pros and Cons of using or not using ESB Tools. Read the following article :

What do you really need within your solution: ESB or Microservices?