Although WSO2 Enterprise Integrator 6.5.0 is not formally released yet, I was curious about the new version and of course about the developer studio that we use to create artifacts for the product. For many WSO2 products you can simply see what WSO2 is doing by looking at the source code that is posted on GitHub. Alternatively, you can also subscribe to the mailing list for developers that will also give insight into the development of new versions as well as some of the discussions that WSO2 is having internally with regards to platform developments. In this blog we will discuss the differences between the current version and and the new version of WSO2 Enterprise Integrator and what features has been changed or added.
When you look at what is available on GitHub you’ll see that there is version 6.5.0 that we are discussing in this blog, but also that version 7, which will be based on the Ballerina language, has been in the making for quite some time. This will of course be a major new version, but we will discuss that in a blog when we’re closer to GA release of v7. The timeframe for version 7 is at this point unclear.
EI 6.5.0
For me as a trainer of WSO2 I’m interested in seeing where the differences lie between the current version and the new version as well as any changes or new features that the product offers.
I downloaded the preview version of developer studio, the 6.5.0-M5 (Milestone 5) release of Enterprise Integrator and, since v6.5.0 of Enterprise Integrator, a separated product called WSO2 Micro Integrator, v1.0.0-M3.
I’m testing this in the Amazon environments that we have up and running for our training courses which is based on CentOS.
Let’s first look at the size of these files. The new WSO2 Enterprise Integrator is pretty much on par as far as the size goes with the 64x version. We have gone down considerably when WSO2 Enterprise Integrator Analytics moved to the stream processor which has a smaller file size due to the fact that it’s on Carbon 5 (C5) rather than the Carbon 4.4 that the other products are still on.
Starting WSO2 EI (plain vanilla) takes about 40 seconds, on par with the previous version. As far as the functionality goes from the management UI, we see few differences if any.
If you want to know what’s has changed inside the product have a look at the release notes. It is always good to also check the Known Issues list for the product so you can see if there are any issues that might hamper deployment. Keep in mind that by default this list shows all known issues until present day, this can be filtered however to show just the issues registered for a specific product or tooling version.
Micro Integrator
WSO2 Micro Integrator allows you to set up a microservices-based architecture on existing Synapse /AXIS2 configurations. In other words, artifacts you’re currently developing for Enterprise Integrator can be deployed in a microservices architecture environment without having to change anything. How is this possible?
Basically, it’s possible because the Micro Integrator is a very lightweight version of Enterprise Integrator.
In previous versions, Micro Integrator was a profile of Enterprise Integrator but with v6.5.0 WSO2 decided to make Micro Integrator available as a separate download. Micro Integrator has everything stripped out that we don’t need in a minimal setup and which would slow down system startup.
Let’s have a look at the structure of the product.
It is a long overview, however, it shows that the structure of the Micro Integrator to a very large extent is comparable to Enterprise Integrator. This is a tree overview where we only show the directories four levels deep. As you can see there is a components directory, a deployment directory etc.
├── bin├── dropins├── updates└── wso2 ├── components │ ├── micro-integrator-default │ │ └── configuration │ ├── p2 │ │ ├── org.eclipse.equinox.p2.core │ │ └── org.eclipse.equinox.p2.engine │ └── plugins │ ├── org.eclipse.equinox.launcher.gtk.linux.x86_1.1.200.v20130807-1835 │ └── org.eclipse.equinox.p2.publisher.eclipse_1.0.0.v20110511 ├── lib │ ├── endorsed │ └── tomcat │ └── conf └── micro-integrator ├── bin │ └── yajsw ├── conf │ ├── axis2 │ ├── data-bridge │ ├── datasources │ ├── email │ ├── etc │ ├── security │ └── tomcat ├── dbscripts ├── dockerfiles │ └── files ├── repository │ ├── data │ ├── database │ ├── deployment │ ├── logs │ ├── resources │ └── tenants └── tmp └── work |
So, let’s try it out. I’ve created a very simple proxy that is basically a pass-through proxy to the echo service that is part of the Enterprise Integrator installation (it is actually an Axis2 service). When you use the WSDL of the service, the echo string allows you to send a message like “Hello Micro Integrator” to the service and it’s actually echoed back to you.
In order to test it out I’m going to develop the service using the new version of Developer Studio that is going to be released together with WSO2 Enterprise Integrator v6.5.0 and WSO2 Micro Integrator 1.0.0.
Of course, I could also have used an older version of Developer Studio but in this case, I’d wanted to see what’s new in Developer Studio.
Developer studio
A trivial but noticeable changes in Developer Studio is the new logo and naming. But do not be fooled it is still based on Eclipse. When you get further into Developer Studio you’ll see the very familiar overview of Eclipse with the project explorer, the developer studio dashboard and all of the other things that we have been using for the last couple of years.
I’m not going to walk through the development of a proxy, if you want to learn more then you’re more than welcome to follow one of our trainings on the Enterprise Integrator. I’m basically going to show you a little bit about the new look and feel as well as the outcome of the proxy.
In the development of the proxy I am going to show you that Micro Integrator has exactly the same internal mechanisms as the Enterprise Integrator.
The proxy that I’m going to develop will be named MI_Proxy. It will be saved in a project called MI_Project, will be available in HTTP and HTTPS and will it call the endpoint URL http://localhost 8280/services/echo. I will add a log mediator to both the InSequence in the OutSequence, both of them being mediators that will display a message in the Console view of Eclipse.
When we start working with this new version of Developer Studio we immediately see some changes. Some of these changes are cosmetic as we now have a new set of icons for mediators. Some of the other improvements are functional so, for instance, in the Properties tab of a mediator we actually have a new interface that will make configuring properties easier, hopefully.
<?xml version="1.0" encoding="UTF-8"?>
|
Looking at the properties of the Log mediator we now have a different way of adding new properties inside to the log mediator using the + and the X icons at the top-right of the properties list.
When we want to deploy a service of course we need to have a server up and running. The new Developer Studio allows us to do that by defining a new server where we now also have Enterprise Integrator 6.5.0 and Micro Integrator as server-types available.
I will define two servers, one Enterprise Integrator 6.5.0 and one Micro Integrator. I will then deploy the artifacts to both servers. What I believe will happen is that the Enterprise Integrator will hot deploy the Car file and make it available immediately, Micro Integrator does not have the hot-deployment feature however so the Car will be copied into the carbonapps directory but it will not become available unless you restart the Micro Integrator.
Enterprise Integrator is easy peasy to setup in Eclipse, however the Micro Integrator server is a little bit more of a challenge. This Milestone release has an issue in the definition of the server as its actually pointing to an older version of a dependent jar file, namely the work.WSO2.carbon.bootstrap – 4.4.36. jar rather than the 4.4.38.jar which is actually shipped with Micro Integrator. Furthermore, there is a double mention of ‘bin’ in the URL as well. Unfortunately, I could not finish the configuration of Micro Integrator due to some strange behavior of Developer Studio. We have submitted the issue to WSO2!
Continuing with just the Enterprise Integrator server, the proxy was saved and I added it to the composite application which I then added to the Enterprise Integrator Server that I just configured.
A quick check on the management URI of Enterprise Integrator shows that the proxy was indeed successfully deployed.
The proxy invocation using its SOAP url returns the message that was expected from the Echo Service.
On the console, we see the two log-mediators that we defined in the In- and the Out-sequences
[2019-04-19 14:07:50,270] [EI-Core] INFO – ApplicationManager Successfully Deployed Carbon Application : Mi_CAPP_1.0.0 {super-tenant} [2019-04-19 14:07:55,308] [EI-Core] INFO – LogMediator Status = I am in the InSequence [2019-04-19 14:07:55,379] [EI-Core] INFO – LogMediator Status = I am in the OutSequenceSo, on Enterprise Integrator 6.5.0 it works like a charm.
|
|
Micro integrator
It’s now time to start with Micro Integrator. Given that we couldn’t add Micro Integrator as a server to Eclipse we’ll go about using the command-line to deploy and start our service.
Micro Integrator does not do hot deployments we need to copy the car file into its deployment directory and we need to start Micro Integrator. We do that, similar to Enterprise Integrator, by going to the bin directory of the product and do an ‘sh micro-integrator.sh’ in a terminal session. While watching the console for any information with regards to deployment of the composite application/car file we can see that in approximately 12 seconds Micro Integrator started successfully and is able to handle invocations. We need to make a change to the Proxy since it will call the Echo Service on the EI (port 8280). I’ve changed the port of the endpoint to 8290 to access the echo service on the Micro Integrator.
The car file was deployed and the proxy is now available to be used.
Compared to Enterprise Integrator we see that Micro integrator uses different ports out-of-the-box. By default, the HTTP listener port is 8290 and the default HTTPS listener port is 8253 for the micro integrator, for the careful reader an offset of 10 compared to ports of the Enterprise Integrator.
So simply changing the port number in the invocation-url of the proxy (and the endpoint of course) that I just used previously should make it work on Micro Integrator. I’ve made the changes, invoked the proxy and result is pretty much the same. The screenshot below shows this.
So how compatible is Micro Integrator with Enterprise Integrator that we’ve been using until now? It is a very good question and it’s not one that is answered within the scope of this document. I tried out a very simple proxy and that worked.
However, trying to access some admin services didn’t work. To some extent this is logical as the admin services are used by the management UI to perform tasks. In other words when you add a user using the management UI, in the background its actually invoking an admin-service that adds the user to the user store. As Micro Integrator is shipped without management UI there is be no need for those admin services either. However, this goes to the compatibility of both products. If you’re using one of the admin services for instance to see whether the server is running you cannot do that with Micro Integrator. There might be many more incompatibilities between this Enterprise Integrator and Micro Integrator but identifying them is not something that I’m going elaborate on within the scope of this article.
Also, the possibility to have Micro Integrator running in a Docker environment is something that is worth exploring. This will be done in a separate blog due to the fact that this blog is already becoming a long read.
Developer Studio
When you say Developer Studio/Eclipse not everyone shows their enthusiasm right away as in the past there were some quirks which required tested the resiliency of the developer. For instance, when developing directly in the source-view of a sequence and making a configuration mistake you were not able to save it. Furthermore, you were not able to switch from source to design if you had such an error in the configuration. In the next version of developer studio this is improved and according to the engineers from WSO2 there is now a new validation layer that will give you more accurate information on the error that you have in yours source plus you are able to save the artifact even if it has errors. In this article you will find an explanation on how this works.
Recently I reused a piece of XML code to do fault mediation. However, Developer Studio did not pick up on that error in the source view. An attribute of the fault mediator that I used had an error as far as the value goes in the code-element. The value=”soap11Env:Sender” does not exist anymore as one of the options of the fault mediator. When I switched back to design-view it actually replaced my value with a random (but existing) value for the code (value=”soap11Env:VersionMismatch”). Making a mistake in the Log mediator category was however picked up, showing a suggestion about possible values.
But there is still time for bug fixing as this is not definitive version. There will be improvements made over time and hopefully that will catch this this error as well. I’m submitting it to the issue list for Developer Studio today so there will be a good chance in the final version this error will be solved.
There is more to be said about the new Developer Studio (like the possibility to generate a Docker Image from a Compsite Application) but that would make the article even longer, so we will keep that for a future blog.
I think that, in all, improving the user interface as well as the performance of Developer Studio is something that we can all benefit from and applaud. So I’m looking forward to the new version of the three products that I discussed in this blog, Micro Integrator 1.0.0-M3, WSO2 Enterprise Integrator 6.5.0-M5 and the new version of Developer Studio.
