You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/02-architecture.adoc
+18-13Lines changed: 18 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,29 +36,31 @@ As a migration does not bring immediate new business value, it's important that
36
36
== An in-depth look at the solution's architecture
37
37
38
38
The Red Hat Build of Camel is an Cloud-native, multi-language and a multi-runtime integration stack.
39
-
Camel-based integration logic can be written in XML or Java, and can behave as a springboot, a quarkus, or a serverless artifact.
39
+
Camel-based integration logic can be written in XML or Java, and can behave as a Spring Boot, a Quarkus, or a Serverless artifact.
40
40
41
-
The present demo will take a legacy API developed in Jboss Fuse 6.2 on Karaf, in Blueprint XML.
41
+
The present demo will take a legacy API developed in JBoss Fuse 6.2 on Karaf, in Blueprint XML.
42
42
It's suggested that such an application targets the Quarkus runtime.
43
-
The provided Quarkus template is 100% compatible with CamelK, so the resutling migrated application is immediately ready to be added to a serverless stack.
43
+
The provided Quarkus template is 100% compatible with Camel K, so the resutling migrated application is immediately ready to be added to a serverless stack.
44
44
45
45
The material can be used to migrate any Fuse 6 or 7 distribution to the Red Hat Build of Apache Camel.
46
46
The demos will however focus on migrating a Fuse 6 application, and more concretely a Camel v2.17 one, in Blueprint XML format, running on Karaf 2. The XML format will be converted to the optimized IO XML one.
47
47
This path has been chosen for the demonstration because it can be considered the hardest one. Applications running on Fuse 7, no matter which distribution, could use the same approach and will bnefit from a shortest migration effort.
48
48
49
49
In general, the following migration strategy should be considered:
50
50
51
-
Language
52
-
* If you have integrations in Java, keep them in Java DSL
53
-
* If you have integrations in XML, migrate to the optimized IO XML
51
+
* *Language*
54
52
55
-
Runtime
53
+
** If you have integrations in Java, keep them in Java DSL
54
+
** If you have integrations in XML, migrate to the optimized IO XML
56
55
57
-
* If you are already on Fuse 7 springboot, migrate toward springboot
58
-
* In any other cases, you could target Quarkus
56
+
* *Runtime*
59
57
60
-
Target
61
-
Probably, the target should remain a "standard" container application, ready for Serverless but not mandatorily a Function.
58
+
** If you are already on Fuse 7 springboot, migrate toward springboot
59
+
** In any other cases, you could target Quarkus
60
+
61
+
* *Target*
62
+
63
+
Probably, the target should remain a "standard" container application, ready for Serverless but not mandatorily a Function. +
62
64
Thus, the demos will showcase several migrations to "plain" springboot or quarkus applications, and there will be one extra demo to showcase a migration from that result to Camel K.
63
65
64
66
@@ -67,10 +69,13 @@ Thus, the demos will showcase several migrations to "plain" springboot or quarku
67
69
68
70
A Fuse / Apache Camel based application can be seen as a composition of multiple layers: the Apache Camel layer, the runtime layer (i.e. OSGI) and the platform layer (i.e. Karaf/Fabric8).
Theoretically, the migration would involve changes in all layers.
73
77
The material here consists in ready to use templates that are already perfectly suitable for the target so that the migration effort will be reduced to a small subset of changes on the Apache Camel layers.
74
78
The templates are Maven artifacts, preconfigured with all required dependencies, and holding all the needed placeholders to migrate code and configuration in a timely fashion.
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/03-demo.adoc
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,11 +14,11 @@ You can see a migration based on the templates in action here.
14
14
15
15
* https://drive.google.com/file/d/11CBxNI_2QI77uFeD7Dxqf32uDnAt9cKX/view?usp=drive_link[Migration toward Camel for Springboot and Camel extension for Quarkus^]
16
16
* https://drive.google.com/file/d/1DqTrlydgvJiKTe7y6oxuvY8K-SAve9xc/view?usp=drive_link[Running the migrated application on Openshift^]
17
-
* https://drive.google.com/file/d/11CBxNI_2QI77uFeD7Dxqf32uDnAt9cKX/view?usp=drive_link[Running the migrated application as a Camelk serverless function^]
17
+
* https://drive.google.com/file/d/11CBxNI_2QI77uFeD7Dxqf32uDnAt9cKX/view?usp=drive_link[Running the migrated application as a Camel K serverless function^]
18
18
19
19
=== Overview
20
20
21
-
The templates are available in the following repository: https://github.com/mthirion/fuse-to-camel3-camelk
21
+
The templates are available in the following repository: https://github.com/mthirion/fuse-to-camel3-camelk[https://github.com/mthirion/fuse-to-camel3-camelk ^]
22
22
23
23
24
24
* The repository has a dedicated branch for each target version: currently *Camel 3.18* or *Camel 3.20*
So, there is a subdirectory for each of the most used Camel components (REST API, SOAP, JMS...) further divided per runtime (Quarkus and Springboot).
33
33
34
-
+
35
-
image:repo-templates.png[width=60%]
34
+
35
+
image:repo-templates.png[]
36
36
37
37
38
38
@@ -85,17 +85,17 @@ Here below, we'll call this namespace 'claimdemo-migration'.
85
85
86
86
$ oc new-project claimdemo-migration
87
87
88
-
==== Preparing CamelK (optional)
89
-
If you want to test the migrated application as a serverless component, you'll need an Openshift server with CamelK installed. +
90
-
Install the Red Hat CamelK Operator to your Openshift cluster.
88
+
==== Preparing Camel K (optional)
89
+
If you want to test the migrated application as a serverless component, you'll need an Openshift server with Camel K installed. +
90
+
Install the Red Hat Camel K Operator to your Openshift cluster.
91
91
Optionaly you can also deploy the Openshift Serverless (Knative Serving and Knative Eventing) operators. +
92
-
Make sure you also have the kamel CLI on your local machine, and of the same version as the CamelK Operator. +
93
-
For clarity, we'll use a separate namespace for Camelk-related artefacts. Let's call it camel-migration. +
92
+
Make sure you also have the kamel CLI on your local machine, and of the same version as the Camel K Operator. +
93
+
For clarity, we'll use a separate namespace for Camel K-related artefacts. Let's call it camel-migration. +
94
94
95
95
$ oc new-project camel-migration
96
96
97
-
Custom beans such as custom Camel processors as considered by Camelk as external dependencies. +
98
-
Those dependencies need to be made available to CamelK at deployment/build time. +
97
+
Custom beans such as custom Camel processors as considered by Camel K as external dependencies. +
98
+
Those dependencies need to be made available to Camel K at deployment/build time. +
99
99
The best way to do that is to use an external Maven repository, such as Nexus. +
100
100
It can be deployed on or outside of Openshift but needs to be reachable from it.
101
101
@@ -214,11 +214,11 @@ To run it and test it on Openshift:
214
214
$ cd -
215
215
216
216
217
-
==== Turning the migrated application into a CamelK serverless function
217
+
==== Turning the migrated application into a CamCamel KelK serverless function
218
218
The template makes use of the new IO XML format, which makes the migrated application immediately compatible with Camel K. +
219
219
220
-
As mentioned, with CamelK, the Java dependencies (custom Camel processor) need to be made externaly available, for example thanks to a Nexus repository +
221
-
To do that, you can use the helpers found in the camelk template directory, which will be refered to as $CAMELK +
220
+
As mentioned, with Camel K, the Java dependencies (custom Camel processor) need to be made externaly available, for example thanks to a Nexus repository +
221
+
To do that, you can use the helpers found in the Camel K template directory, which will be refered to as $CAMELK +
222
222
223
223
$ CAMELK=./templates/camelk
224
224
@@ -227,7 +227,7 @@ There are 3 elements to modify in the helper: +
227
227
[upperalpha]
228
228
. *Import of the Java library* +
229
229
+
230
-
Copy the org.blogdemo.claimdemo.ClaimProcessor java class to the camelk "javadependency" directory.
230
+
Copy the org.blogdemo.claimdemo.ClaimProcessor java class to the Camel K "javadependency" directory.
231
231
232
232
$ mkdir -p $CAMELK/javadependency/src
233
233
$ mkdir -p $CAMELK/javadependency/src/main
@@ -282,7 +282,7 @@ Edit the CamelBeans.java file in the following way:
282
282
}
283
283
284
284
+
285
-
You are ready to deploy the application as a CamelK Integration +
285
+
You are ready to deploy the application as a Camel K Integration +
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/index.adoc
+12-11Lines changed: 12 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,11 +8,11 @@ Application Development is evolving as the modern Hybrid Cloud and cloud-native
8
8
9
9
As Red Hat Fuse approaches product End of Life (EOL) on June 30, 2024, Apache Camel is the natural go-forward solution for integrations built around Red Hat Fuse which is based on an older version of Apache Camel. Fuse will remain in the https://access.redhat.com/support/policy/updates/jboss_notes#phases[maintenance life cycle^] until its EOL.
10
10
11
-
The Red Hat build of Apache Camel is the evolution for Red Hat Fuse, and is a powerful, versatile framework for application integration. It also includes running Camel on Quarkus and Spring Boot runtimes in both on-premise and cloud environments, including the Camel K operator which is the best starting point for Camel deployments on OpenShift.
11
+
The https://developers.redhat.com/products/redhat-build-of-apache-camel/overview[Red Hat build of Apache Camel^] is the evolution for Red Hat Fuse, and is a powerful, versatile framework for application integration. It also includes running Camel on Quarkus and Spring Boot runtimes in both on-premise and cloud environments, including the Camel K operator which is as great starting point for Camel deployments on OpenShift.
12
12
13
-
Performing such a migration can be scary as the effort is not just limited to migrating the high level Camel routes. Indeed, many other underlying technical components (JDK version, Runtime type, XML format...) are involved in the migration.
13
+
Performing such a migration can be scary as the effort is not just limited to migrating the high level Camel routes. Indeed, many other underlying technical components (JDK version, Runtime type, XML format etc.) are involved in the migration.
14
14
15
-
With this solution pattern you will find a guided way to perform Apache Camel v2 to Camel v3 or v4 migrations in a faster way. This solution pattern proposes an accelerated path to performing such a migration by abstracting all those technical details, leaving it to the migration of the high level integration logic .
15
+
With this solution pattern you will find a guided way to perform *Apache Camel v2 to Camel v3 or v4 migrations* in a faster way. This solution pattern proposes an accelerated path to performing such a migration by abstracting all those technical details, leaving it to the migration of the high level integration logic .
Common use cases that can be address with this solution are:
24
24
25
-
- migrate Fuse 6.x (Blueprint XML, Spring XML or Java) applications to the Red Hat Build of Camel, targeting either Springoot 3, Quarkus or the CamelK Serverless runtime.
26
-
- migrate Fuse 7 (Karaf or Springboot) applications to the Red Hat Build of Camel, targeting either Springboot 3, Quarkus or the CamelK Serverless runtime.
27
-
- start writing Camel 3.x or 4.x applications right away with no effort
25
+
- Migrate Fuse 6.x (Blueprint XML, Spring XML or Java) applications to the Red Hat Build of Camel, targeting either Springoot 3, Quarkus or the Camel K Serverless runtime.
26
+
- Migrate Fuse 7 (Karaf or Springboot) applications to the Red Hat Build of Camel, targeting either Springboot 3, Quarkus or the Camel K Serverless runtime.
27
+
- Start writing Camel 3.x or 4.x applications right away with no effort
28
28
29
29
30
-
== The story behind this solution pattern
30
+
== The Solution
31
31
32
-
The development team of Globex, the fictitious retail company, has been tasked to study the migration of the legacy Fuse 6 of applications to the new, cloud-native, serverless Red Hat Build of Camel.
33
-
At first glance, the migration seems to require a lot of effort, as changes must happen at all technical layers of the applications.
32
+
This solution aims to provided an accelerated path to migrating applications from Camel 2 to Camel 3 or Camel 4. More concretely, the material should help people migrating any kind of Fuse 6 or Fuse 7 applications to the latest Red Hat Build of Apache Camel.
34
33
34
+
The Solution Pattern offers a number of *Camel migration templates* which can be leveraged to reduce the migration effort to its bare minimum.
35
35
36
-
== The Solution
36
+
The demos however focuses on migrating a Fuse 6 application, and more concretely a Camel v2.17 one, in Blueprint XML format, running on Karaf 2. The XML format will be converted to the optimized IO XML one.
37
+
38
+
This particular usecase has been chosen for the demonstration because it can be considered as potentially the hardest one. Applications running on Fuse 7, no matter which distribution, could use the same approach and will bnefit from a shortest migration effort.
37
39
38
-
The dev team decides to leverage the Camel migration templates in order to reduce the migration effort to its bare minimum.
0 commit comments