A common use case we get in IIB is the implementation of JSON to SOAP integration where you may have an existing service which is a webservice with SOAP/HTTP and you would like to expose it as JSON for the REST architecture style in the world of cloud and mobile.
If you look at the implementation domain where such a service may sit. IIB is a suitable candidate for such implementation as mostly all the SOAP service in your enterprise would be behind a Datapower or any other network appliance. You may not want to add additional logic of transforming protocol on the Datapower layer.
IIB 10 does provide valuable feature of directly converting a message flow to support REST, and you can even deploy the flow to the cloud. We would not be talking about the cloud side of it. Lets just talk about the basic implementation of JSON to SOAP using IIB 10.
I would be using a feature of IIB 10 here where you can define mapping without having a model/schema first, you can start your map and then later model the source and target messages.
If you look at the implementation domain where such a service may sit. IIB is a suitable candidate for such implementation as mostly all the SOAP service in your enterprise would be behind a Datapower or any other network appliance. You may not want to add additional logic of transforming protocol on the Datapower layer.
IIB 10 does provide valuable feature of directly converting a message flow to support REST, and you can even deploy the flow to the cloud. We would not be talking about the cloud side of it. Lets just talk about the basic implementation of JSON to SOAP using IIB 10.
I would be using a feature of IIB 10 here where you can define mapping without having a model/schema first, you can start your map and then later model the source and target messages.
No comments:
Post a Comment