question about switchyard example, JSON, transformers

[anthonyhib]

Hi,

I must be missing something obvious but I'm spending too much time on this.

Why isn't it possible to reproduce the switchyard-quickstart-transform-json example from scratch?

I mean, I start creating the project using SY 1.1.0, but when I want to add the JSON transformers, the tooling tells me that all required transformers have been created.

I've seen a jira issue (1524) explaining that is normal but:

- if that's normal, why an official example is doing another way?

- what would be the use case where the tooling would explicitly propose me to add a JSON transformer? In jira the answer is

you will notice that the interface declared on the composite service is the same as the interface declared on the component service, so no transformation is required

-> what kind of interface would force the tooling to propose a JSON transformer?

Thanks for your support,

Anthony

[kcbabo]

We should really update that quickstart so that it has a composite service with a binding, which would make it a lot easier to understand what is going on.  Right now, it uses our unit test framework to trigger the transformer, which is handy, but requires a deeper level of understanding in terms of how things are wired together.

The important thing to understand w/r/t declarative transformation is that it only kicks in when the runtime detects that the message type is different between the consumer and provider contracts.  The tooling reflects this as well, which is why if there are no interactions where contract types differ, then you cannot create a transformer.  There are three scenarios in SY where the contract types can differ and require a transformation:

1) A composite service interface is different from the component service interface it promotes.

2) A component reference interface is different from the component service interface it is wired to.

3) A composite reference interface is different from the component reference interface it promotes.

Back to the transform-json quickstart, it gets around this by using our unit test framework to explicitly set the consumer contract to something different than the provider contract (OrderService):

quickstarts/transform-json/src/test/java/org/switchyard/quickstarts/transform/json/JsonTransformationTest.java at master…

So if, for example, you promoted that service with a contract where the interface types are different, then you could create a transformer.  You can either use the ESB interface type or use a Java interface in combination with the @OperationTypes annotation to set the type name to something different.  See Content Type Names here:

Transformation - SwitchYard - Project Documentation Editor

hth,

keith

[anthonyhib]

Yes I found a composite service was required in order to run the example.

Still on the JSON side, would it make sense to add a *format* parameter while setting up a binding (let's say file) .

For example, I know my file only contains JSON and I directly want to transform this into a JAVA object and pass it to my interface method?

Or is this something that should always be done in the implementation it self.

[sardeenz]

This and many of the other quickstarts are a big turn off.  Most folks just want to invoke/consume an 'external' restful service that serves up json and handle the response.  It's not hard to do, but you wouldn't know that from the quickstarts or any documentation that can be found.  Also, who knows what to use in the enterprise, fuse? switchyard? soa-p?, eap 6.1 (only?), as5,6, 7-wildfly? jboss esb 5 or 6? and forge doesn't seem to work in at all unless you use some crazy combination of different outdated versions.  I'm a big fan of what switchyard is potentially capable of and my team has been able to build some interesting things (for those of us who could get the proper pieces installed and configured in eclipse), but we're still just poking around in the dark to get any added value.  Sorry for the rant, and I will work to provide some more constructive comments, but sheesh, a supposed file based json transformer without any clear description of what's going on or what it is doing much less any real world application just adds to the confusion.  My business pays for a SOA-P subscription, but find it unusable, took the SOA-P Jboss ESB training class and exam, failed miserably since the training prep had nothing to do with the exam questions.  Switchyard is our first hope in success.

[kcbabo]

OK, let's take this a step at a time and work on things that the SwitchYard community can actually help you out with.

First, I highly recommend having a look at the labs we have available in the SY learning repository:

Learning SwitchYard : Labs from Red Hat Summit Available

Even though that might not have the exact scenario you're looking for, it does provide some solid background on the concepts involved with using the project.  If you run into any setup issues getting that going, come back to us and provide specifics.

Second, the quickstarts exist to provide an example of using a particular feature of SwitchYard.  We try to make them relevant, easy to run, and document what actually happens.  We find that most users like to pick them up and run them as is, then start to tweak them a bit to explore functionality that is not directly demonstrated.  If there is a big hole in terms of demonstrating a feature, then let us know.  If the docs don't provide enough information, let us know.  This is a community effort.

Finally, I'm sorry to hear that you have had trouble with SOA-P in the past, but I'm glad that you are looking forward to using SwitchYard which is now supported by Red Hat as part of Fuse Service Works.  As an existing customer, you are entitled to support as you work your way through using the product.

[kcbabo]

Lab 2 in the learning repository demonstrates a JSON transformation on an external call from an app.

[hitesh.goradia]

Hello Keith,

We are evaluating Switchyard 2.0 (alpha) for one of our SOA solution.  We were able to successfully invoke REST based service without any issue when we promoted component service as composite service with REST binding. However, we are facing issues (may be due to not enough knowledge around Switchyard internal wiring) when composite service contract is different from component service contract. We would like to evaluate Switchayard out-of-box JSON transformer to transform java type to JSON string when REST based service is invoked/consumed. We are not sure if we fully understand what needs to be done to make this happen. Could you please send us the step by step instruction for this to happen? Please do not point us to the Switchyard project documentation or quick start as it is not very much useful for us.

Thanks in advance for your quick response to this.

HG.