All posts by Afkham Azeez

Introducing WSO2 Enterprise Integrator 6.0

WSO2 started out as a middleware company. Since then, we’ve realized – and championed the fact that our products enable not just technological infrastructure, but radically change how a company works.

All over the world, enterprises use our products to maximize revenue, create entirely new customer experiences and products, and interact with their employees in radically different ways. We call this digital transformation – the evolution of a company from one age to another, and our role in this has become more a technology partner than a simple software provider.

In this realization, we’ve announced WSO2 Enterprise Integrator (EI) 6.0. Enterprise Integrator brings together all of the products and technologies WSO2’s created for the enterprise integration domain – a single package of digital transformation tools closely connected together for ease of use.

When less is more

Those of you who are familiar with WSO2 products will know that we had more than 20 products across the entire middleware stack.

The rationale behind having such a wide array of products was to enable systems architects and developers to pick and choose the relevant bits that are required to build their solution architecture. These products were categorized into several broad areas such as integration, analytics, Internet of Things (IoT) and so on.

We realized that it was overwhelming for the architects and developers to figure out which products should be chosen. We also realized that digital transformation requires these products to be used in certain common patterns that mirrored five fields: Enterprise Integration, API Management, Internet of Things, Security and Smart Analytics.

In order to make things easier for everyone, we decided to match our offerings to how they’re used best. In Integration, this means we’ve combined the functionality of the WSO2 Enterprise Service Bus, Message Broker, Data Services Server and others; now, rather than including and setting up many many products to implement an enterprise integration solution you can simply download and run Enterprise Integrator 6 (EI 6.0).

What’s it got?

EI 6.0 contains service integration or service bus functionality. It has data integration, service, and app hosting, messaging, business processes, analytic and tooling. It also contains connectors which enable you to connect to external services and systems.



The package contains the following runtimes:

  1. Service Bus

Includes functionality from ESB, WSO2 Data Services Server (DSS) and WSO2 App Server (AS)

  1. Business Processes

Includes functionality of WSO2 Business Process Server (BPS).

  1. Message Broker

Includes the functionality of WSo2 Message Broker (MB). However, this is not to be used for purely message brokering solutions; this runtime is there for guaranteed delivery integration scenarios and Enterprise Integration Patterns (EIPs).

  1. Analytics

The analytics runtime for EI 6.0, useful for tracking performance, tracing mediation flows and more.

In order to provide a unified user experience, we’ve made some changes to the directory structure. This is what it looks like now:

The main runtime is the integrator or service bus runtime and all directories relevant to that runtime are at the top level.

This is very similar to the directory structure we use for other WSO2 products; the main difference is the WSO2 directory, under which the other runtimes are available.

Under the other runtimes, you find the same directory structure as the older releases of those products, as shown below.

One might ask why we’ve included multiple runtimes instead of putting everything in a single runtime. The reason for doing so is the separation of concerns. Short running, stateless integrations will be executed on the service bus runtime while long-running and possibly stateful integrations will be executed on the BPS runtime. We also have optional runtimes such as message broker and analytics which will be required only for certain integration scenarios and when analytics are required, respectively.

By leaving out unnecessary stuff, we can reduce the memory footprint and ensure that only what is required is loaded. In addition, when it comes to configuration files, only files related to a particular runtime will be available under the relevant runtime’s directory.

On the Management Console

There’s also been a change to the port that the management console uses. The 9443 servlet transport port is no longer accessible; we now use the 8243 HTTPS port. Integration services, web apps, data services and the management console are all accessible only on the passthrough transport port, which defaults to 8243.

Tooling

Eclipse-based tooling is available for the main integration and business process runtimes. For data integration, we recommend using the management console itself from the main integration runtime.


Why 6.0?

As the name implies, EI is an integration product. The most widely used product in the integration domain is the WSO2 Enterprise Service Bus (ESB), which in the industry is known to run billions of transactions per day. EI is in effect the evolution of WSO2 ESB 5.0, adding features coming from other products. Thus, it’s natural to dub this product 6.0 – the heart of it is still the same.

However, we’ve ensured that the user experience is largely similar to what it was in terms of the features of the previous generation of products.  The Carbon platform that underlies all of our products made it easy to achieve that goal.

Migration to EI 6.0

The migration cost from the older ESB, BPS, DSS and other related products to EI 6.0 is minimal. The same Synapse and Data Services languages, specifications and standards have been followed in EI 6.0. Minimal changes would be required for deploying automation scripts such as Puppet scripts -the directory structures are still very similar, and the configuration files haven’t changed.

Up Next: Enterprise Integrator 7.0

EI 6.0 is based on several languages – Synapse for mediation, BPMN and BPEL for business processes, DSS language for data integration.

A user who wants to implement an integration scenario involving mediation, business processes, and data integration has to learn several languages with different tooling. While it’s effective, we believe we can do better.

At WSO2Con 2017, we just unveiled Ballerina, an entirely new language for integration. EI 7.0 will be completely based on Ballerina – a single language and tooling experience. Now the integration developer can concentrate on the scenario, and implement it using a single language and tool with first level support for visual tooling using a sequence diagram paradigm to define integration scenarios.

However, 7.0 will come with a high migration cost. Customers who are already using WSO2 products in the integration domain can transition over to EI 6.0 – which we’ll be fully supporting – while planning on their 7.0 migration effort in the long term; the team will be working on tooling which will allow migration of major code to Ballerina.

WSO2 will continue to develop EI 6 and EI 7 in parallel. This means new features and fixes will be released as WUM updates and newer releases of the EI 6.0 family will be available over the next few years so that existing users are not forced to migrate to EI 7.0. This is analogous to how Tomcat continues to release 5.x, 6.x, 7.x and so on.


EI 6.0 is available for download at wso2.com/integration and on github.com/wso2/product-ei/releases. Try it out and let us know what you think – it’s entirely open source, so you can take a look under the hood if that takes your fancy. To report issues and make suggestions, head over to https://github.com/wso2/product-ei/issues.

Need more information? Looking to deploy WSO2 in an enterprise production environment? Contact us and we’ll get in touch with you.

 

What’s new in MSF4J 2.0?

The MSF4J team is excited to announce the latest release of WSO2 Microservices Framework for Java (MSF4J) 2.0!

MSF4J is essentially a lightweight, high performance framework for developing and running microservices.

This release comes with a number of major enhancements and features:

  • An improved thread model and transport architecture
  • Spring and Swagger support
  • ExceptionMapper and StreamingOutput support
  • More powerful form submission commands
  • Circuit Breaker state management based on Nygard’s pattern

Let’s examine these in more detail.

Improved thread model and transport architecture

The default thread model in MSF4J 1.0 included the Netty boss threads handing over the requests to Netty worker threads, and the microservice requests being executed using the Netty worker threads. However, this leads to the problem of the Netty worker thread pool getting exhausted if the threads took long to execute or were blocked. That results in requests being dropped.

With the new thread model, service requests are executed using a separate executor thread pool (application thread pool) by default. There is also the option of handing over the incoming request to an LMAX disruptor which is useful in certain scenarios. As a user, you will have full control over configuring these thread pools.

image05

MSF4J thread model. S in the diagram is your MSF4J service.

MSF4J 1.0 also had a direct dependency on Netty, but with 2.0, we’ve brought in an abstraction called CarbonMessage. CarbonMessage will represent the request and response messages, irrespective of the underlying transport technology.

Spring support

image01

Spring is a popular framework among developers because it provides a very simple dependency injection (DI) mechanism which makes life easy for developers. We decided to support Spring owing to popular user demand for dependency injection support.

MSF4J now supports a Spring-native programming model. You can now write your MSF4J microservices, Interceptors, ExceptionMappers and configuration as Spring beans and wire them up at runtime.

The standard Spring configuration annotations such as @Component, @AutoWired and other Spring features work with MSF4J, making it easy to bring in other 3rd party libraries and wire them in at runtime. For example, those who are familiar with Spring-JPA can use the Spring-JPA library to integrate the Hibernate ORM framework with a MSF4J service. The Spring sample demonstrates this feature in action.

Swagger support

image00

Swagger is a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

This feature allows you to add Swagger annotations to your microservices to enrich the Swagger definition of your service. Please note that if Swagger annotations have not been used, the feature will still generate a basic Swagger definition by going through other JAXRS annotations in your service.

The stockquote service example demonstrates Swagger annotations in action. After running that sample, you can retrieve the Swagger definition of the service by going to http://localhost:8080/swagger?path=/stockquote.

javax.ws.rs.ext.ExceptionMapper support

An ExceptionMapper maps a Java exception to an HTTP response that is to be sent back to the invoker of the MSF4J service. This feature allows Java developers to throw business logic exceptions from their MSF4J services, and if there are ExceptionMappers registered to handle such exceptions, the toResponse method in those mappers will be invoked.

image03

Directly returning Java stacktraces to clients is a bad practice. As  a best practice, a properly designed HTTP response which doesn’t expose critical internal implementation details or security details should be returned.

ExceptionMapper allows Java developers to write their code using Java best practices, i.e. throw exceptions when exceptional conditions are encountered, and also follow best practices in service design by not exposing internal details by returning stacktraces.

The stockquote service example demonstrates ExceptionMapper in action.

javax.ws.rs.core.StreamingOutput support

image02

Streaming file download

StreamingOutput gives the developer full control over how the response from your microservice is going to be streamed. You can choose the size of the chunks that are going to be streamed. Depending on the available resources to the JVM, you may select your chunk sizes. For example, smaller chunk sizes will allow you to operate with a lower server side memory footprint. However, note that this may cause the clients to experience higher latencies. The idea is that you can choose a chunk size that is a good tradeoff between memory footprint and latency.

A practical example could be streaming a large file to a client or reading a large number of records from a database and streaming data based on those records.

The FileServer example demonstrates StreamingOutput in action.

FormParam and FormDataParam annotation support

The @FormParam annotation supports HTML form submission with application/x-www-form-urlencoded and multipart/form-data MIME types. The value will be automatically converted to the corresponding parameter type and assigned to that parameter in the MSF4J service operation.

The difference between @FormParam and @FormDataParam is that FormParam can support only Java Strings and primitive types (int, long, Integer, Long etc). The @FormDataParam annotation, on the other hand, can support complex types and Collections, with multipart/form-data content type and support for files along with form field submissions. These can be directly submitted to a MSF4J service and will be handled seamlessly.

The form service sample demonstrates this feature in action.

FormParamIterator

In certain case, a user may want to have full control over the incoming message stream from form submissions, for performance optimization reasons. This can be achieved using the FormParamIterator. When a FormParamIterator is declared as the only parameter of your service operation, MSF4J will hand over full control of the stream to you. The FormParamIterator is injected via the @Context annotation.

This feature is demonstrated in the form service sample.

CircuitBreaker support

Nygard’s circuit breaker pattern defines that rather than wasting valuable resources trying to invoke an operation that keeps failing, the system backs off for a period of time, and later tries to see whether the operation that was originally failing works. This is now supported supported in MSF4J using the Netflix Hystrix library.

image04

Circuit breaker lifecycle

In the context of microservices, a typical usage of circuit breakers would be when one microservice calls another or when a microservice calls out to an external system. In such cases, these calls will be wrapped in Hystrix commands which will take care of handling the circuit breaker state management. The circuit breaker parameters can be configured as per the configurations listed athttps://github.com/Netflix/Hystrix/wiki/Configuration.

This feature is demonstrated in the MSF4J circuit breaker sample.

As you can see, we’ve added quite a bit to the second version of MSF4J. Try out MSF4J 2.0 and let us know what you think – it’s free and open source.

WSO2 Summer School returns for the sixth year

It is officially summer in the northern hemisphere and as always we are happy to summer-school-2014-logobring you our popular Summer School program. Since 2009, our interactive web-based program has helped thousands of architects and developers learn about upcoming technologies and best practices for integrating and deploying enterprise applications.

This year for our sixth year of Summer School, we have exciting new classes on IoT to discuss the latest developments and get a deeper understanding of the challenges that lie ahead.

I will be kicking off the first session tomorrow, providing an introduction and reference architecture for IoT. This session will be followed by:

Don’t miss out on this once-a-year opportunity to boost your knowledge on the evolving needs of  today’s enterprise – register today!

– Afkham Azeez, Director of Architecture at WSO2

Twice the Capabilities, Half the Name

Not every Web Application has a corresponding Web API, and not every Web Service has a corresponding Web interface, but we’re seeing steady growth among customers who are building Web Applications and their APIs together.  These APIs are invaluable for leveraging advanced users and integrating with partners, but also are driven by a demand for rich applications such as native iPhone, iPad, and Android applications.

In response to this growing demand, we’ve added an exciting new feature to the WSO2 Carbon family: full support for Apache Tomcat, the leading open source servlet container. We’ve added this feature to the WSO2 Web Services Application Server — our Apache Axis2-based platform for hosting Web Services and APIs.

image_thumb[4]

As demand grows for Web APIs side by side with Web sites, a unified server provides a powerful and convenient way to provision and host both capabilities on a single server runtime, manage them through a unified console, with a single set of administrator privileges.  This unified approach offers double the benefits but at much less than double the complexity — all the benefits of the WSO2 Carbon framework, and all the skills you have in managing them, can now be applied to Web Applications.  Even multi-tenancy for deployment in the cloud — more on that in a subsequent post!

What better way to celebrate the lean nature of the product than with a new, leaner name!  appserver_logo_h23With version 4.0, the WSO2 Web Services Application Server, now no longer limited to just Web Services, is now called simply the WSO2 Application Server.  Download it today or try it out as a service at https://appserver.cloud.wso2.com!

Afkham Azeez, Senior Architect and Senior Manager

Azeez’s blog: http://blog.afkham.org/

A WSO2 First: Multi-Tenant Tomcat WebApps

In a previous post I talked about the advantages of unifying Web Applications and Web Services or APIs into a single server runtime.  And about some of the advantages of making Apache Tomcat part of the WSO2 Carbon family.

Tomcat LogoBut there possibly isn’t any aspect of a Carbon-based Tomcat more exciting than combining it with the power of WSO2 Stratos, the WSO2 Carbon-based cloud middleware platform.  Stratos provides hosting on the cloud with all the advantages that implies: the agility of instant self-service provisioning, elasticity to automatically scale up with business peaks and down as demand subsides, the efficiencies of multi-tenant architecture, and greater intelligence through full monitoring and metering.

As a WSO2 Carbon family product, this means Tomcat Web applications can be deployed on the cloud!  Either on your private cloud infrastructure, or on the WSO2 public cloud, relieving your businesses of the chore of maintaining their own IT infrastructure.

We’re very proud to offer the first commercial release of Tomcat available as either server-based software, a virtual machine image, or as a multi-tenant platform as a service (PaaS) on private or public clouds.

You can try the Tomcat WebApp samples, deploy your own WebApp, and more at https://appserver.cloud.wso2.com.

Afkham Azeez, Senior Architect and Senior Manager

Azeez’s blog: http://blog.afkham.org/