We are investigating whether or not we can use the WSO2 - ESB as our new platform.
With our current esb we connect external systems to each other over different channels like JMS,FTP,JDBC.
Most of the interfaces are independent of each other. The number of interfaces we have now is about 300.
The processing in each interface consists of :
- connecting to the external systems
- logging the in + outgoing messages
- transformation of the incoming message into an outgoing message.
The transformation of the message is programmed in java.
Since the interfaces are independent of each other, it is not an option for us to stop other interfaces
when we need to deploy a new ( or modified existing ) interface.
What I understood from WSO2 esb is that when using a custom mediator to transform I have to restart the WSO2 - ESB server
when the implementation of the custom mediator changes.
This is not what we want unless it is the only interface running on this esb server.
What are my options given these constraints:
The update of an existing interface should not have any impact on other interfaces.
The transformation of the messages is programmed in Java.
The number of interfaces is around 300.
Usually WSO2 ESB has rich set of mediators to handle transformation and perform mediation it seems you need more than that. You can use Developer Studio, Eclipse based IDE to add a custom mediator without restarting the server. please refer this for more details.
Related
How compatible WSO2 DSS for application development?
It means, we need to write all of our transaction (insert, update, delete, select) in the DSS.
There are any pros / cons?
I'm not sure, but some of big query takes long time over the web service.
Any suggestion or case study for application development.
BR,
Eba
WSO2 Dss is very flexible and have enough features for you to use it for app development. You can expose all your data services ops(select,update,delete,insert and any complex data base stored procedures) thru wso2 DS, and invoke them in a light weight manner from your apps. i.e You can you can expose each such operation as SOAP/REST. In your case, exposing them via REST is the way to go. If you want you can expose a set of ops as a group and etc. There are quite a few such useful features in DSS you can find as a app developer.
THis is the wiki doc for WSO2 DSS https://docs.wso2.org/display/dss311/WSO2+Data+Services+Server+Documentation.
Here is how to expose data services as REST resources
https://docs.wso2.org/display/DSS311/Exposing+Data+as+REST+Resources
Can someone plese help me answer the following three question on WSO2:
Does WSO2 Studio support tool based graphical xslt transformation, right now I have to map it to a xslt file created using text editor?
Do all the invocations on WSO2 ESB have to be exposed as "proxy services", be it consuming a jms message or reading from a file system?
Do we have out of box adapters in WSO2 ESB to talk to external systems like SAP, Oracle Apps, Siebel, Peoplesoft etc in a drag and drop fashion without any glue code to be written?
Thanks,
Wajid
Q1. Does WSO2 Studio support tool based graphical xslt transformation, right now I have to map it to a xslt file created using text editor?
Answer:
There is an ongoing effort to implement a Graphical XSLT Transformation tool for Developer Studio. But as I mentioned it is a work in progress. Thus will be available in a future release.
Alternatively, if you are interested you can use existing Smooks editor to perform XML to XML mapping and Graphical Smooks editor in WSO2 Developer Studio will help you to create your smooks configuration with much less effort.
Q2. Do all the invocations on WSO2 ESB have to be exposed as "proxy services", be it consuming a jms message or reading from a file system?
Answer:
If you want to consume a JMS message from a queue or Reading a file using VFS transport, usually proxy services are configured to perform those tasks. But of course you can use Sequences to perform those tasks but then, you need to use these sequences in your proxy service or in REST API.
Q3. Do we have out of box adapters in WSO2 ESB to talk to external systems like SAP, Oracle Apps, Siebel, Peoplesoft etc in a drag and drop fashion without any glue code to be written?
Answer:
No.
Currently IPaaS connector support is not there out of the box for Developer Studio ESB Graphical editor. But it is in Developer Studio road-map which means it will be available in a future release of Developer Studio.
Hope this helps!
/Harshana
You can use the default XSLT editor which comes as a XSLT mapping tool or the smooks (recommended for large message processing)editor. Some of the adapters can be found from here.
Thanks
I am working on WSO2 ESB 4.0.3 on MAC OS X Lion (10.7.4)
I would like to know what are the best practices for development for WSO2 ESB 4.0.3.
Currently I am using Data Services Feature in it and existing tomcat application, which we are trying to port to WSO2 ESB, does the SQL query in 2-3 seconds where as WSO2 ESB 4.0.3 with Data Services feature taking around 16-17 secodns.
I would be thankful if some body can let me know best practices for WSO2 and in perticular XSLT transformation.
Hoping for answer.
thanks
Hi Prabath
Here is how my environment is
I am using WSO2 ESB 4.0.3 with Data Services Feature 3.2.2. Proxy service front ends the DS service. Data sources are defined as carbon data sources in datasources.properties.
I tried to run the same service in the WSO2 Data Services Server 2.6.3 and the performance is comparable to what existing tomcat application does but the ESB 4.0.3 with Data Services Feature 3.2.2 takes 8 times more time than tomcat application. Looks like XSLT is not a issue as I thought earlier.
I have all the error handling & input validation in the proxy service which calls this DS.
Also I tried changing it to local for the transport but still same performance issue. Also I have to make sure the format of the forwarded XML is SOAP 12 in the end point definition otherwise proxy service does not forward with local transport.
Can you please suggest so that I can use WSO2 ESB with Data Services Feature 3.2.2 and get comparable performance?
Help really appreciated.
thanks
Abhijit
Hi Prabath
Thanks for reply.
Proxy service validation and transformation is not a problem. Looking at the logs it looks like Data Service deployed in ESB with Data Services feature is taking 8 times more time than the tomcat application. So it is Data Services Feature which is problem I believe and not the proxy service.
Even if we remove the proxy service where you will do the input validations and error handling?
Please let me know.
thanks
Abhijit
Abhijit,
I'm not quite clear of whether this problem is related to executing SQL using dbReport/dbLookup mediators against doing the same thing having data services features installed in ESB OR transforming responses using XSLT at the ESB layer against doing it at the DSS layer.
If it's the former, then you should be able to effectively use the db mediator pair (namely dbLookup and dbreport) to execute simple SQL queries such as SELECT, INSERT, UPDATE, DELETE, etc. However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.
If this is related to the later, meaning, if you refer to the XSLT transformations, I believe there's no such hard and fast rules in doing this and this would completely depend on your requirements and the usecase. For example, if you're only using WSO2 DSS and want to get some request transformed into a particular format that is expected by the client side, it would only be enough for you to get it done at the WSO2 DSS layer. Because, dispatching it into ESB ONLY for the sake of getting the XSLT transformation done, would add an additional unwanted overhead to the end-to-end completion time of your task. On the other hand, if you're doing this as a part of a configuration flow at the ESB side, then it's perfectly okay to use something like XSLT mediator inside the flow itself.
Hope this helps!
Regards.
Prabath
I hope Prabath already gave the answer to your question.
However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.
I have two Spring applications. One of them manages data storage (backend), the other communicates with users (frontend). Now I need to connect these two applications with ESB (Probably Fuse ESB) using web services (so probably CXF binding components). Could you explain to me how to achieve this functionality step by step?
I have Service interface and its implementation on backend Spring application.
Thanks for replies
Any Messaging protocol (JMS, AMQP, TCP etc.) would allow you to connect two apps that run in different JVMs together.
Have you look at Spring Integration project? You really don't need ESB for that.
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs