We are happy to announce the availability of Xsemble 3.0. It can be downloaded from the Get Started page.
Xsemble 3 is a major release. It aims to shoot beyond the Java EE technology that it has been supporting from the beginning. Most of the changes in this major release revolve around this theme, apart from other improvements and bug fixes. In this blog post, we explain this main feature — the multi-tech support.
Multi-Tech Support Implementation
Xsemble was created as a platform-neutral technology. It supported Java EE from the beginning. The depth of functionality provided was increased with every new release. Now with Xsemble 3, Xsemble grows sideways as well. It’s been retrofitted to add support to other languages and frameworks. This support is demonstrated with one other technology, namely PHP.
Technology Cartridges
You need a technology cartridge to have your Xsemble installation support the corresponding technology. While the technology cartridges for Web and Java EE technologies are provided with Xsemble, the technology cartridge for PHP technology is provided as an additional download on the Get Started page.
As described on the page, you need to place this cartridge under the ‘tech’ subfolder of your Xsemble installation. If you already have Xsemble running then you will need to restart it to have the support added.
Components Support Multiple Implementations
The Xsemble components now support multiple implementations. These implementations are typically from different technologies (like a Java implementation and a PHP implementation), but in case you want to create different implementations corresponding to the same technology for some reason then that is allowed too.
We have added PHP implementations to the components under the Demo1.HelloRepo repository provided with Xsemble. Shown below is a dialog box that edits the “Get Name” component. It is a “Page” component and represents a web page. Note the highlighted “Implementations” section. The two buttons “Legacy Java” and “PHP web” correspond to the Java EE and PHP technology based implementations of this component respectively. Below those, you will find the controls that are used to create a new implementation.
Multiple Implementations Can Share Resources
Life gets interesting when these disparate implementations can share resources. In the demo example provided, the “Legacy Java” and “PHP web” implementations of the “Get Name” page use the same css and images. They therefore look exactly the same, as shown in the figure below. The fact that they are two different applications is only given away only by their different URLs (highlighted).
Left: PHP implementation running on Apache2 server, Right: Java EE implementation running on Tomcat server
Project Layers Dictate the Base Component Implementations for Nodes
The layers defined at the project level correspond to the architectural layers of the target application.
Let’s understand them with two demo projects “Demo1.Hello” and “Demo1.Hello PHP” provided with Xsemble. They are replicas of one another in Java EE and PHP technologies respectively. Their flow diagrams look identical, but they define the server side layers differently, as seen in the following diagrams.
In the figures, the name appearing in brown color after the layer name is the name of the platform. Xsemble supports certain platforms (based on the technology cartridges used), and a layer is always based on one of them. In the figures you will see that the layer names have their names same as the names of the platforms, though it is not a must.
As one would expect, there needs to be a technological compatibility between an implementation of a component and the underlying platform. For example, a Java implementation would be executed on a Java EE platform and a PHP implementation can be executed on a PHP platform. You cannot do it the other way round.
Let’s see this in action. The “Ask name” nodes in both the above projects are Page instance nodes. They both correspond to the same base component “Get Name”. It is a Page component that we have already seen above. The two figures below show the relevant part of the edit dialogs of these two page instances. Note how the component implementations are compatible with the layers.
In case you are wondering, the “Layers” dropdown in the above illustrations shows the names of two layers, separated by arrow (->). This is typical of the Page instances in the scenario of web applications. It indicates that they get created in the server-side layer (Java EE or PHP web) and get displayed on the browser-side layer (Web). For other types of components, you will see the name of a single layer there, indicating that they belong completely to the selected layer.
Xsemble has a technology model inbuilt into it. It understands which technologies are compatible with which platforms. It tries its best to prevent you from making a selection that is incompatible. This tech compatibility check is a very handy as it goes multi-tech.
Implications of the Multi-Tech Support
Increased Reach of Xsemble Technology
The most obvious implication is that now you can use Xsemble to create applications in PHP (or further languages / platforms, as their support gets added). Consequently, the usual Xsemble benefits apply to them as well:
- Programmer’s focus reduced to developing a single component in isolation
- Visual assembly of software based on these tiny components
- Reduced effort, higher reliability
- Quantitative inputs for better manageability
- Increased enhanceability and maintainability
Development of Microservices
As noted before, the project layers are basically the architectural layers in the target application. As we also saw, each of these layers correspond to a target platform defined within Xsemble.
These layers are immiscible. The presence of more than one server-side layers indicates creation of different deployables. Xsemble delivers you the complete source code and the deployables at the end of the burn process. These deployables may be deployed independently of one another, and possibly as multiple instances for high responsiveness and resilience. As one may realize, this is the microservices architecture. The salient benefits of using Xsemble for creating microservices are explored in another 2 part article.
The new multi-tech support means that in addition to Java EE, you can now use PHP technology (or other technologies as they get supported) to create your monolythic or microservices based application. Further, it also means that you can create a microservices application where different microservices use different technologies. The application can still be visualized in terms of the control flow and the data flow, even when the flow traverses through distinct platforms.
As discussed in our Microservices articles, conventionally the development effort gets broken down to small teams, and with Xsemble it gets further broken down to individual level. You also get better synchronization at the boundaries of these microservices. This reduces the effort while increasing accuracy.
Better Type Support => Robustness
Programming languages that use dynamic typing or duck typing have always lagged behind the programming languages that use static typing, in terms of creating robust applications. PHP, Python, Javascript are some examples of the former and Java, C, C++, Typescript are some examples of the latter. The lack of type-checking in the former ones opens up the possibilities of variables of incompatible types being passed around, causing havoc when it is least desired. Therefore, in spite of the popularity of these languages, their penetration in enterprise space where high robustness is desired is negligible. Xsemble can help writing robust programs using these languages due to its inbuilt type support.
The in and out arguments of the functional components in Xsemble are statically typed. The data nodes that appear in Xsemble projects also are associated with these types. Consequently, the data connections in Xsemble which are made between the instances of these components and the data nodes can be validated for type compatibility. The “Health Check” facility in Xsemble carries out these validations and dutifully reports any issues, as seen below.
Note that this facility is available irrespective of whether the underlying programming language has static type checking. Therefore, the Xsemble components implemented even with a duck typed language are still type-safe to use. The implementation code within a component is expected to be quite small, so manual checks would be enough at that level.
Thus, with Xsemble, you can get the best of both worlds:
- Using the duck typed languages for their popularity and productivity for component implementation
- Yet benefiting by the type safety that Xsemble provides at component definition level
Conclusion
The multi-tech support featured with Xsemble release 3 opens up some interesting new possibilities which did not exist before. More important than adding support to PHP is the fact that it is a clear demonstration that other languages / platforms may be supported as needed.
Download Xsemble and check out the demo applications provided with it to get a first hand feel. Xsemble comes with a User Guide and Reference Guide. We have strived to make the documentation up-to-date with the new features. Please check it out. Let us know if you start seeing some interesting ways in which it could work for you.
