Towards the end of webcast,you are talking about API wrappers for ESBs to communicate with APIGEE.Please correct me if I am wrong.
In my scenario,I am trying to have SOAP to REST conversion in APIGEE by importing WSDL in APIGEE.And by doing so,I am trying to connect with external world from APIGEE through REST.And to internal applications is from APIGEE to Datapower.And this later part is through SOAP.Here I am not using any API wrappers or libraries for Datapower.By importing WSDL into APIGEE,APIGEE directly could communicate with Datapower.And Datapower to backend systems.Could you advise if this is right approach?
Also,if we say the applications transformation into APIs and APIGEE as the gateway ,I am not sure if we can completely have solution for all kinds of ESB scenarios.Especially Message collection (Check here).Kindly share your thoughts on this.
Do you mind starting this comment as a new question? Could add a link to this thread just for context. This will make it easier to parse through information for others looking for the same info.
Btw, LOVE your questions, keep them coming what a great way to create shared knowledge by everyone.
âI am not sure if we can completely have solution for all kinds of ESB scenariosâ
I am certain you cannot. If you try, youâre going to run into trouble. Some patterns you may be able to get near, or find workarounds for.. others, like with the collection example you link to, youâll find trouble implementing. The risk, IMO, is that while you may find a way to do it with some combination of persistence either in KVM or BaaS and perhaps node.js or Java programmability youâll run into problems when we go off the happy path and need to try to recover from an error of some sort. Once you add multiple, stateless code execution nodes and eventually consistent persistence the challenge of replicating some of those ESB patterns safely becomes a real problem. I would advocate for re-designing the API rather than trying to lift and shift the same logic from SOA/ESB to the API world.
Hello again @RK4. Just now getting around to responding to these.
I see you mentioned Message Broker for the first time in this discussion thread. So, it sounds like you have implemented the standard IBM Integration/SOA pattern with Broker as the Integration Bus and DataPower as the Gateway (front door) sitting in front of it.
I would expect the performance of XSLT to be better on DataPower (hardware appliance)than on message brokerâas I noted in my last post, that is what it does.
As @Dino and others have pointed out, you will have to test the performance of XSLT against your message types on Apigee to see how it performs. I wouldnât assume anything.
In general, I think XSLT is the right tool for the job when dealing with XML-to-XML transformations. But, as you noted, performance can become a concern. Again, test your use case with XML messages that test what your system would see for real.
As for other potential approaches, Apigee supports (in addition to XSLT) Python, Java, and Javascript. Any of those would be capable of manipulating an XML message. Those all give you plenty of room to get yourself in trouble. And, call me a broken record, you will have to try it with your specific use cases:). If XSLT doesnât work out, Iâd try Java nextânoting, of course, youâll have to try it with your specific use case.
Iâm going to reply to your other post below about ESB patterns and Apigee to keep things readable.
I wouldnât describe it as âAPI wrappers for ESBs to communicate with Apigeeâ. What I was describing in the WebCast was using Apigee (as an API Gateway) to provide a wrapper around existing SOAP Web Services. Those SOAP Web Services were advertised/secured/other-things using the IBM Integration Stack as an ESB pattern. In that particular shop, there were also APIs advertised on the ESB (Broker + DataPower). There was a desire to continue to leverage the IBM infrastructure that had been deployed and extend the integration stack capabilities into the cloudâthatâs where Apigee Edge came into play.
The term ESB(Enterprise Service Bus) can mean numerous different patterns. If you are using your ESB for asynchronous messaging or complex orchestration(between several services), these are probably not things you want to to do with Apigee (@Dino or others, please comment). You could probably do some things, but others would likely get difficult (as noted by @Carlos Eberhardt above).
Another approach would be to replace datapower as the âESB Gatewayâ. It sounds like some of the earlier posters are doing this. I suspect it is the most common approach. At this point, Apigee is the gateway to the ESB(message broker), but, not the part responsible for persistence or asynchronous messaging. Another approach would be to continue using DataPower for SOAP/XML and using Apigee for APIsâhaving both of those on premise would likely create far more political drama than any problems it might solve. That approach wouldnât be my first choice.
Bottom line, Apigee could fill the role of datapower in your ESB pattern. It isnât a good match for replacing message broker. Iâm working with a shop right now that is having a similar conversation. They are looking at using Mule (deployed to the cloud) as a migration path away from Message Broker (IIB). Whether you call this Apigee + Mule construct an ESB is open for debate, but that would then be able to address most of the same use cases DataPower + WMB/IIB are for you today. The are other products on the market that could fill this role. Mule works well especially if you are already working in a Java shop. It should also be noted that Mule has an API Management product that does similar things to Apigeeâjust to make this more confusingâI donât really have any experience with it.
As always, test things before committing to a direction.
Thanks a lot @Robert C. Broeckelmann Jr. for your clear explanationâŚI am starting with my usecase keeping all of these in my mind.Thumbrule as you and @Dino adviced : "test things before commiting "
Also @Birute Awasthi ..I love this forum because even if we are ignorant while asking questions,we are enlightened by the answers shared by experts.Experts are very much approachable .My learning curve in APIGEE is good because of this forumâŚ
what a great way to create shared knowledge by everyone.