Why does the management console provide features to develop a service or customize a component of WSO2 ESB?
What's the purpose of one Vs other?
Doesn't the development stops after handover of CAR files/artifacts to DevOps team?
My understanding with Management Console is to deploy, manage(start-stop) & monitor ESB services/integration flows.
Is there an overlap on these two ? The documentation itself provides two ways to do the same thing. I mean why?
TIA,
--M
All these features are available in Management console for users to try out easily. For example, when they want to see what are available feature etc, quickly.
When you're using ESB in real development, you should use toolings instead.
Related
Can I publish an agent version on an environment using the Dialogflow V2 API?
I can't find any documentation on how to do that.
The doc about versions and environments only mentions doing this using the console (https://cloud.google.com/dialogflow/docs/agents-versions).
And the API doc of the agent environments resource only contains a list method (https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.environments).
Does it mean that every change done using the API is automatically reflected in production?
Or does it mean that every change done by API is staged, and can only go to production by manually accessing the console and publishing the new version?
Both options seems terrible by the way.
Currently, it's not possible to manage agent versions through the Dialogflow API, it seems that this feature is already being contemplated to be integrated to Dialogflow; however, there is no an ETA for its implementation. You can follow up this request here.
While evaluating various ESB's, I came across Apache Synapse & WSO2. In WSO2 it's mentioned that WSO2 completely uses Synapse and built on top of it.
However I am not still clear what additional features does WSO2 offer over Synapse? (Apart from commercial support).
One difference I could see is the web UI to manage proxy definitions, sequences creation etc. Are there any other features which WSO2 provides over Synapse? Also please share if there are any guidelines to choose between Synpase & WSO2
I just wanted to be sure why I am going to WSO2 over Synapse.
Thanks,
Harish
WSO2 ESB offer many great features on top of synapse. I am listing few here.
Graphical management console to create/manage/monitor proxies/APIs and services.
Support for many transports [1].
Statistics, logging and auditing support
Support for many content types
And industry accepted proven performance.
List can go on and on. Hence I am referring you to WSO2 documentation on features[2]. Hope you can get some idea from there.
[1] https://docs.wso2.com/display/ESB481/ESB+Transports
[2] https://docs.wso2.com/display/ESB481/Features
WSO2 Carbon is not officially supported in webapp mode (see the selected answer here). However, I have no choice - If I want to run carbon, it must be run in webapp mode.
There are some detailed instructions here for setting up carbon 4.x in webapp mode.
I am concerned is that standalone mode is strongly recommended by WSO2.
My Questions are: What are the limitations:
when running Carbon 4.x in webapp mode?
when running other Carbon based products (e.g. ESB, AS, etc) in webapp mode?
If possible, please provide a detailed list of the limitations.
Limitations:
When you take the ESB, as you might have seen it exposes ports 8280/8243 (HTTP/HTTPS) in addition to 9763/9443 which is exposed through the servlet transport. In the case of ESB you need (and want) to use port 8280/8243 when you're interacting with the ESB because those are the two non-blocking high performant transports. When you deploy ESB on top of another web container, you're limited by the servlet transports provided by the container. So we can't get the desired performance out of the ESB for proxying and other scenarios.
Complexities involving using web container functionalities. Carbon has its own clustering/caching/security etc... infrastructure. When you deploy Carbon as a webapp then we should look at supporting all those functions provided by the container for different containers. Which is complex, not consistent and in some cases sub-optimal
IMHO those were the two most important factors why it's discouraged to deploy Carbon on top of other containers. Going with a standalone deployment approach it has contributed immensely to not include web container specific "hacks" into the platform to get things done and have a much cleaner consistent platform.
One issues with deploying Carbon in web-app mode is that this deployment model is not supported by WSO2. I will add more issues to this answer as I encounter them...
AFAIK, webapp is not supported... Please refer this thread :Running WSO2 Carbon as Web Application in Tomcat
Regards,
Mohan
I need to develope WAS application and should be hosted into Demandware platform. Can i develop the WAS application using tomcat and can host it into the Demandware or should WAS application be developed in the Demandware platform?
I am new to Demanware platform and WAS. Guide me.
You cannot build a web service outside of the UX Studio paradigm like what you described, but you can build a psuedo-service like pipeline in UX Studio that returns JSON, XML, etc. and it will work more or less just like any other REST service.
Demandware is Software as a Service (SaaS) provider, which will not allow you to access the underlying infrastructure (e.g. Tomcat server, Oracle DB, etc.) to make/install your custom extensions.
UPDATE (25.09.2015):
Currently Demandware are making extensions to their controllers, migrating from pipeleine-based controllers to script based ones. Chances are that at some point they may even introduce an API for creating web-services.
Until this happens, your only option is to make some custom pipelines and utilize something like XML/JSON over HTTP for this type of functionality. (Or if you insist on having it as SOAP based service, you would need to parse the SOAP envelopes with explicit code)
Demandware platform is a proprietary technology which allows developing only using their sandboxes and own IDE "UX Studio". All this stuff is available for demandware developers on their xchange portal. Access there could be requested by a merchant you do a development for.
Demandware has the core framework is closed to third parties and is exposed via the Demandware script and REST API's as well as Demandware's own Pipelet system.
Sadly you can't deploy external application in Demandware server, we have to separately create new app in UX studio
You can get the proper help on Demandware Wiki or on Exchange
I am wondering if any of the open source ESB provides strong change management capabilities:
ability to version services, components, rollback changes, compare
changes.
And if it could log which user has made changes and what is the
change to the application.
That's not an ESB ability.
But usually ESBs can behave like app containers (as in David A Chappell's Enterprise Service Bus book chapter 6). So the app/modules can be versioned.
For instance: Mule ESB can behave like a container. Mule provides a maven archetype for creating mule apps. Those apps can be commited to an version control repository. The hot deployment abilities of the container, should be enough to "rollback" changes.