 Welcome everybody. I'm Kevin tongues from the North America go to market team. Very excited for this next presentation about fuse eight and really getting into that pathway to move from our integration components to Where that modernized space is so I'd like to welcome my good friends Sergio and Michael and really excited to hear you guys presentation today. Sergio, let me hand it over to you. Okay, thank you very much, Kevin. So, yes, let's see the agenda. This is the breakdown of the agenda that we have prepared for today's session. The first topic is what happens with fuse eight. We are going to explain the reasons that we rebrand the name. Also, we are going to give you some reasons if you are using now fuse six and seven. Why you should migrate to latest version of camel and we are going to give you some information about how to migrate your fuse six seven To the last heart build of camel and the last topic is is a live demo that we are going to show you is how a service made in the fuse six OGI how migrate this service to come along with us. So, let's jump for the next topic. Okay, that is what's next after fuse seven. So, if so, the story began in 2007, a group of engineers from active MQ open source project decided to create a camel in order to implement enterprise integration patterns. These are the results of a study that observe the communications between services and systems in 90. And they determined that all communication between services can be defined in one or many interaction patterns. They define as a list of roughly 60 patterns. And the idea is to reuse when you need to make an integration is to use all of these patterns. So, and that it was the beginning of Apache camel project. And behind of this project, it was a company, it was a fuse source. This company was acquired in 2012 by Rothat. And one year later, a few six, they came out a few six was based on coming to and and support the OGI and Java to the architecture. And if you don't remember that was the time that of enterprise service buses platform. So, so the in that time, the old integrations were recommended to centralize all the policies, governance and services on on that. And the applications were made, based on the three entire architecture that now that literature we call as monolithic. In 2018, the fuse seven was released. We continue to support in OGI and Java to E, and we include capabilities for managing micro services. Also, we started to support a spin boot. And the idea was that in 2022, this fuse eight that that is the new release of fuse is based on common three and micro services and cloud and designed for cloud native. And what happens with that fuse eight? So, make a can you move. So, what the that happened was that the fuse eight was rerunded to camel. Indeed, we had a bit of Apache camel. And why the main reason is because the upstream project Apache camel is very popular and is we need to leverage that that priority. And the also in is one that is an important thing because, as probably you know, Apache camel in terms of contributions is the is the is the most popular interaction framework in the open source community. And, and this is something that that you can take advantage if you use it. And in this work at camel, we include three different flavors, the camel core tremendous same for those three flavors. And what we give you is the option to simplify the implementation of camel at depending on the requirements that you have. We provide camel extensions for Quarkus. And that is the support of camel. If you want to leverage the Quarkus runtime and that that provides you that high performance and on the low footprint. And if you want to use the integration services in OpenShift, you can use camel game. And that is a way to with very low code to allow you to deploy that and define integrations on OpenShift. And also we provide support for camel and then the runtime is the spring and one important thing here is that the camel interfaces remain the same from the beginning. So that is a benefit if you want to migrate from one version to the other version, because if you for instance take a getting a static guide that was released in 2007 and you take a look at today if you will see that the DSL, the objects like camel processor and camel root remain the same. Particularly the same. So that that is a benefit if you want to migrate. Move the slide please. Yes, and why I migrated to camel some reasons for migrating from a few six seven are a site of the support ability that this is something that we always recommend that if you put this a code in production that should be supported is the security. The security we have added this security patches on the stream project also we support the image of for camel on on deployed on OpenShift that that image is has installed all the security patches on that from the operating system. And another reason is the modernization as you saw before few six and seven was what they did they were focused on the OGI and Java 2E architectures and now probably you are doing a process or a project for modernize your applications and that happens the same with integration frameworks that that is important to to to have is a is a is a more integration framework and our reason is the distributed integration that the requirements for an integration tool has been changed. Now we need to provide that integration tool is capabilities of integrating legacy systems and also new one systems and services the services has been changed. And it's important that the integration services must be close where the services that you want to integrate are deployed and if now the you can deploy this services on different clouds and and the platforms and that is the one of the of the key values of the new. Red Hat camel and the original reason is that the. The camel is a cloud native integration framework. And that is important because you can leverage the the scalability and the and the facility that gives you that that is this product has been designed for for that. So that is agnostic in terms of infrastructure and if you can you move the slide please and down into this idea that what does mean a cloud native application. So Red Hat camel followed all of these principles that is based on services architecture is also you are able to to package the the old integration services as a containers. It is capable of deployed in different or in the distributed platforms and independent of the cloud provider and very very important is that that you are able to integrate the lifecycle of all of these components in your current applications lifecycle. And here is the very good point because you're able to use is the if you are implementing for the sake of strategy in your your company or the code can be storing the keeps the repository can be deployed on your Kubernetes platform. And the next slide please and also is important that the Red Hat camel has been designed to integrate that league with offensive and leverage the record ecosystems. Red Hat camel is not alone in the in the world so you need some of our capabilities and functionality in order to run your applications and the Red Hat camel provides integration with three scale with service registry it integrates with Prometheus and the distributed pressing in order to. Retrieve information about open telemetry and it also is integrated with. So next slide please. And in a need in addition you can leverage the integration with source less that that is is very important and and and can impact in your. In your co-provided building. Because that is the capability that allows you to reduce to zero the resources that are running integration. Services when no system is calling them so that that is a very interesting feature and and and this is that. That's something that you can leverage with Red Hat camel. So Michael I'm going to hand over to you. Okay thank you very much. So now I would like to to discuss a little bit about how. Wait how to migrate because. Okay on one hand we can be very excited by experimenting and taking benefit of from the the new modern distributed server less integration framework but we still have to go through this migration process and if you are. Running for example few six which is now a little bit behind that's an activity a migration that can be a bit scary because there will be we can expect we can anticipate changes at multiple. Levels like the OS GI for example if you were using to six on OS GI is going to to to change even the open JDK is going to change with an impact on some libraries like JXB. Cara for fabric will be translated into something else could be communities could be could be could be another platform and at the camel layer we just saw that camel was. Upgraded from version two to version three so this could be this could be a bit scary but and indeed if we if we break down the different activities that this migration can can lead to. We have impact really concrete impact everywhere so for the JDK I said the JXB is no longer with the migration of the open JDK the JXB is no longer in the Java course so we need to add it as a as an explicit dependency. If we were using OS GI well things like features lists they have to become modern dependencies on the platform if I want to migrate from few six to something running on Kubernetes I need to think about the best practices on such a platform so best practices around. Containerization like relaying on config maps relaying on health check and things like that and on the camel side well if I was using for example blueprint XML which was very common with a few six. Well I will have changes in the XML because the namespaces are not the same the structure of the XML is not blueprint anymore. Then there are differences in the way the modules are compiled some components has been renamed and some components has been have been dictated. So actually we thought about about how to make it easier for the people being in few six and few seven to go to the rather build of coming so we started to think and we took a community initiative and the team thinking was OK if I want to do if I wanted to do this migration what would like what would like it to be. And we thought that well basically I wanted to be limited to the only thing that I absolutely have to change like for example the component being renamed OK I can take care of that it's not going to be a big deal the functionalities are the same just the naming the change so I can translate that very easily. Deprecated components yeah OK if I was using XML JSON I have multiple possibilities to work around that I need to choose one the best for me I can take care of that. However changes in the platform changes in the runtime changes in the open gdk I don't really want to take care of those changes I would like something to do that for me and so we took the initiative to create some templates. For spring boot and for for spring boot for caucus and for camel K that would actually abstract all the technical details. And what and the migration hopefully will be reduced to just the the things the functional things that are mandatory to change like the name of some components and the deprecated components. And so at the end what I would like the migration to be is that I would like to have a kind of a framework. I just need to put my camel application onto that frame that framework the one that I choose the spring boot one the caucus one of the camel K one and one is done I will just have to take care about a few things like what is deprecated and there there is a very limited number of components that have been deprecated. Okay so I think the best is that I try to show you. So let me try to show you what it looks like. So the templates are in this. Get a repository. So it's totally public can go there you can contribute can feel free to to to have a look. So you will have a directory called templates where the templates are they are sorted by application type. So there is a rest rest type of application so HTTP or in queue are very typical kind of applications. You will also find all the instructions to migrate those to port an application to to those each of each type of application to to the to the the latest version of the rather build of camel. There are a few examples of application also in the in the repository and what I would like to try to do with you now is to take a rest API implemented into six that's going to be something like blueprint XML OS GI API implemented with 6 FRS which was the library at that time which doesn't exist anymore so indeed the the the the migration needs to needs to be performed there. And I would like to try to to migrate it with you with the templates I will do it manually you will see that it's easily easily can be easily automated I'm going to do it. I'm going to do it do the migration manually so that you have a feeling of what it would look like and what what the what the effort is with the templates. I've already downloaded the templates and the application I put everything into the same directory so that I'm going to use this this VS code to migrate and I put everything into the same directory. So we have the two templates the caucus one the spring boot one the camel care one and the claim demo is the is the few six six application that we will migrate. Everything is visible here so that will be very handy to perform the migration. So the source application runs on the good old fuse fabric 6.3 if I'm not mistaken. So I've just launched a fuse fabric with podman in a local docker container here. And what it's a rest API so what it looks like is is that so if you've been using few six you recognize the port 81 82 very very common for a fuse fabric. And the CXS prefix which was also very common for every kind of application implemented with CXS. You will see here that there are two times the status in the URI and actually it's on purpose we will we will consider that this is the kind of mistake that we want to correct as part of the migration. And we will see here that thanks to the new way to deploy rest API with camel with camel three. That's something that is very easily a transparently modifiable with simply with an open API spec. So this is an example of the response that it gives so let's just give some information about the claim that has been raised by I'm going to try to zoom in a little bit so that you can see what. This okay so it just gives some information about about a claim that has been raised. And so that's why this is a few six application that's right to migrate it as fast as possible to either caucus or spring boot and what I propose is that we do caucus and spring boot at the same time. Because the purpose of the template is to abstract that so that should be should be a really very easy to do both. I'm going to zoom in a little bit here as well so there are a few steps there's no specific order we just need to complete all the steps for the migration to be to be to be finished. So we can start for example by the configuration. So let me try to zoom in a little bit I'm not exactly sure how I can zoom in here but maybe once it's in on the on the right it will be clear. In a few fabric you had this concept of pit properties right so the properties were externalized into into a pit file. You just need to take that the content the full content of your pit file and you place it in the respective application of properties of the two templates. So here for example this this one is the CQ's common extension for caucus so this one is a caucus one. I'm just copying at the end of the file I'm copying everything that is in the pit properties and I do the same for spring boot same location. At the end of the file I just place all the variables that I want to use. And so that's done for the for the configuration I need to migrate the roots of course that's the core of the application. So the blueprint or is something that looks like that. So here what is important is that you take only the root part you don't take everything you don't take the camel context you don't take the whole file. You just take the bare minimum which is the root right the logic. And you migrate it to the you place it to the placeholder which is in camel there is an XML file here. You just replace the placeholder with your root you do that for caucus you do that on spring boot is the same. Okay now if you look at the root you see that it uses a custom processor says something very very common in camel to have an external external processor written in Java. So first thing of course is that you need to import the Java package very easy you just take the full package and you place it into the Java folder for both caucus. And spring boot. Now if you remember in a blueprint or OS gi you had to actually declare register the custom processor into the bean registry which was in the outside outside the camel context here. With the with this line here there is a slight difference between the two templates because this actually is totally screen compatible. So if you aren't thing good you have a file a placeholder of almost the same same type of file and you just need to play the exact same line there. This format this beans file actually doesn't really exist for caucus. So with caucus you actually has to use annotation so that's a little manual process here you need to use annotation to do the same thing in quarters. Let's pay attention to the name of the BID. So we've migrated the roots but the roots let me take back the blueprint XML it's an API right so it was implemented with 6 FRS library doesn't exist anymore in camel three now the best way the recommended way to define API is to use the camel. The camel rest component and with the camel rest DSL as well. If you use the rest DSL you have a separation of concern that is very nice so you have the implementation in one place which is the camel roots and you have the definition of the API of the API in another place in another file so you can do the management and the governance of the API with a more flexible way. So how does it work well that's quite easy the only thing you need is the open API spec of your API it's a very good practice to always have the open API spec of all your APIs. So if you don't have them I would consider that maybe this is a prerequisite for the migration to have proper open API that will help a lot after the migration to apply global governance API management and so on over the API. So I actually created this one because it didn't exist for this particular few six applications so I created it with Epicureo API designer and I exported it as a YAML file. So all templates both templates have a modern plugin to generate to generate the camel code that you need for rest API based on open API spec. So the only thing you need to do is a new place your your open API spec into I'm going to take for example the Quarkus one into the source main spec folder. And then you can immediately go and use the use the Mavin plugin so if you use Mavin camel rest DSL open API and then the goal would be generate XML if you are if you prefer to work in Java you can generate in Java as well. But starting from a blueprint XML it makes sense to keep using XML. So once it's done you should find in target generated XML file with the exact representation in camel of a rest API. So you just take that and you place that in the place order which is the rest dot XML file for both templates. Just put it there here and for string boot that's exactly the same location same file you place it here. Now how does the link how does it work I mean how is it working from the rest definition and the rest implementation well it's by the operation ID which is just here and comes from the open API spec. So you just take the ID you go to your roots and you replace the CXF line with the operation ID and you can do that both in Quarkus and thing good. And that's pretty much it. There is one more thing that you might want to do and that depends on what would be the clients of your the clients of your API after the migration because if your client applications were already CXF based application you might have this in your application like the operation name. It's a requirement it's something used by the CXF framework. So you might have this operation name in the in the header and to actually to help know which Java which Java method to call and things like that. So if you want your application to be compatible with new clients which are not CXF you need to kind of remove it. So best way to me what the good way to remove it is to actually clean clean up your file. Well there is a very easy way to remove it is you do something like that. And that works as well. So you can do that like that in both and that would do the job. One thing that you can clean up as well just because we remove the dependency to CXFRS so the Java API the Java version of the API that was used by the CXFRS server. You can you can actually remove that and you can do that for both Spring Boot and Quarkus and normally you're good to go. So let's give it a try. So this one is the Quarkus one. So if I do in Quarkus above hopefully if I haven't forgotten anything it should give something. Okay so if I go back to my REST API and it's it's so that it makes the migration transparent. So it's gonna it actually maps the the new application to the same port and it keeps the prefix the CXF prefix. We just decided thanks to the open API spec that we would simplify and restore the API to the to the to the one with only one status. So if I do that in theory I should have found sorry. So what did I what did I oh yeah. Oh yeah sorry I need actually to exit from my fabric because it keeps my port 81 82 busy so the application couldn't actually go to the port. So let me just restart it. Now it should have taken the port. So if I go there now I should have the same responses before and we are we are already running on Quarkus should do the same for Spring Boot. So just in case we want to be sure if I do that here I should also have my application already migrated on Spring Boot same thing it makes it transparent. So URL would be with 81 82 CXF you can change that very easily with the application the properties. Otherwise if I go this one I have the same answer already and I'm on Spring Boot. So another thing that I want you to know is that the templates are made so that you can run the application on VM if you want to stay on VM. But the application is already ready to be containerized. So if you want to have your application on OpenShift you just do a modern install and you activate the OpenShift profile. The template already takes care of creating everything that needs to be created. So which means the service the routes the config map everything something that I forgot to mention we just saw it the templates already. The templates have a unit and integration test included just to accelerate the life cycle. So that will take a couple of minutes. It's an S2I build that is started by the template. If I go actually I have my OpenShift running here. So we see that the build is already is already starting is already running. So the templates make the application ready for OpenShift. It makes also the application ready for camel K. If you want to run it as a function you can run it as a function as well. So I'm not sure I still have time to show that to you. Maybe maybe do I. Yeah, let's try. So if you want to make it to deploy it on camel K that's even easier because for camel K the application is just that the XML with the route. If you have a custom processor that will be treated as a simple Java dependency. How do you make a Java dependency? You put it in a Maven project. You export your Maven project into Nexus. So let me show that to you. And this is because this format we take the route. Remember we didn't take the camel context. It makes it automatically compatible with camel K. So for this application on OpenShift is almost ready. We're going to test that just after. Let's take care of camel K now. So if you want to deploy your application to camel K you need to have your processor as a dependency. So very easy. You take your Java folder. It's here. There is an empty Maven project in the camel K templates which is called Java dependency. So you can use it. You just put it in source main Java. You put your file. This one I don't need it. And you just need to make sure in the form.xml that you have the root to your Nexus correct. I have deployed the Nexus here. So I just need to take the root so that it's correct. I'm going to put it here. So here there's nothing specific. It's just a simple dependency that you put into Nexus. So if you do Maven deploy it should put your dependency directly into your server. So I go back here. This one. The release one. Dependency is right here. And then to run your application on camel K there's just one line. There is just one thing that I need to do because in this version it's an old version of camel K on my server. It's a 1.8 I think we are at 1.12 now. It just as it creates the properties all the properties it makes it in the palm dot XML that it generates. So I just need to make sure that the application that I want to deploy doesn't have special character. And so I'm going to just comment those line because the person sign is going to trouble a bit the process. Otherwise the only thing that you have to do now is to reference the bean that you want to use as a processor. That's very easily done. It's a Java file. So you import what you just need to have your bean with the bind to registry. So I'm putting bind to registry. I put the bean ID the same as before. And I just need to instantiate this bean so that it will be in there. There will be an instance in the registry and the package if I'm not mistaking is this one. Very good. All right. And that's it. If I now do something like this. So Camerun and then I just pass my XML and I add my dependency here. I will have my few six application deployed to OpenShift as a function instead of as a pod. I'm running out of time I think. But we can see if we look at the pods here. So the application that is deployed as a standard pod has been created here. There is the template created a service. It created the root created everything. So in theory if I take this and I replace that part by my roots, my OpenShift root. I will also retrieve my response and we will see in a few seconds that my camel K application is building. And in like five seconds from now we should see this to be ready. Just to show you that in a few steps you can go from few six to Quarkus or Spring Boot on VM or on OpenShift or on serverless. So it should be recreating the container now. So now we see it's a camel K function now. It should have a root here and actually I'm going to just replace this part. So sorry I've been a bit quick but just to show you now this is the function that is actually returning. A little bit out of time. Sorry for that. I had to go very fast limited time but you can see that in less than half an hour I could have a few six application on camel K. Thanks for the time. That is fantastic you guys that was an awesome presentation Michael Sergio thank you very much for such a great run through. There's one question that came in let's just hit it really really fast. Looks like it would you say that it's the same amount of effort for Spring Boot as for Quarkus the demo seems to suggest so. So they could skip Spring Boot if they wanted to and just go to Quarkus if that was their their their goal is that is that a fair statement guys. Yeah I would say that so Quarkus is probably a better run time if your target is a serverless framework and a function as a service framework. Now if you start from Spring Boot already okay that makes sense that maybe you stay on Spring Boot because you have all the knowledge. I would say that if you start from anything else in your SGI car off things like that targeting Quarkus is probably a little bit better the effort is exactly the same as targeting Spring Boot. That is perfect well I hope that gets your question in that was a fantastic question. Thank you everybody for joining thank you again Michael and Sergio and good luck with the rest of the sessions thanks.