wso2 - should I implement my services as WSO2 Carbon OSGi Custom Components or by using the WSO2 Product stack? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

The high degree of modularity encouraged by OSGi is desirable for a set of SOA services that I am working on.

Each service will consist of a back end service (which includes some persistence) a service interface (e.g. SOAP/REST) and a front end UI.

The native carbon product seems to be a nice fit whereby my services would be created as custom OSGi Carbon components.

What are the pro's and con's of custom OSGi Carbon components versus using the WSO2 Stack (DSS, ESB, AS, etc) for implementing SOA services?

Summary of responses received

As this question has been closed, this is a summary of the responses received.

Reasons for creating WSO2 Custom Carbon Components (OSGi) based SOA services:

• You are extending WSO2
• You already have OSGi components that you wish to reuse
• You would like to reuse the Carbon UI framework

Reasons for using WSO2 Product based SOA services

• Ease of monitoring and management of service lifecycle using Carbon admin UI
• Easier to develop SOA functionality (no java code required for ESB and DS functionality

I guess a combination of approaches could be used, for example backend service created as WSO2 Product based service and front end created as a WSO2 custom carbon component?

Answer 1

If you're providing the UI for your service in the Carbon admin console itself, which probably means you're extending/enhancing product functionality then yes, you must go down the path of writing OSGi bundles. Example: you're adding a new throttling algorithm which allow users to configure new throttling policies through the admin console which accepts many different parameters.

If you're developing functionality which will be used in a user level application, then you're not suppose to go down the OSGi path. Unless you're enhancing/modifying the platform you don't have to know anything about OSGi. For end users, when configuring the ESB, you don't have to write custom code unless your scenario cannot be configured with the existing mediators. ESB and DSS therefore follows a configuration driven approach (for end users) when you have to develop new services.

Answer 2

custom OSGi Carbon components

I believe that you have implemented your services as OSGi bundles. So, the service control can be done by at OSGI level. If you look at our carbon admin services, those are OSgi services and you can control them at OSgi level.

using the WSO2 Stack (DSS, ESB, AS, etc) for implementing SOA services

Here wso2 stack provides to implement an interface for an existing service (eg: esb proxy), or exposing an existing data layer to outside the world( eg: DS) or You can implement your own services, which are in common pattern such as spring/*.aar and deploy them in (eg: AS)

For my understanding, OSGI service and the services which you try to create using wso2 stack , both should work without any major issues.

But when comes to monitoring, i think OSGi services wont be that much easy, since you have to use OSGi commands..