DM between Connector invocations is the prime candidate for the application of this concept. As we are quite certain on what needs to be done from ESB level, we have to work closely with the DevS to get the story right.
On Tue, May 20, 2014 at 5:18 PM, Jeewantha Dharmaparakrama < jeewan...@wso2.com> wrote: > As we discussed we will be adding getInputType() getOutputType() methods > in the AbstractMediator which can be overridden by the Type aware > mediators. Type aware mediators can be > > * All connectors > * All transformation mediators > * Enrich > * Property (When xpath, json path is used) > etc > > There are non-type aware mediators like > *** send > * property with no xpaths/json paths. > etc > > Also there is a third category where the input/output types are not > defined or can change dynamically. For example > * switch > * filter > etc > > So when Data Mapper mediator is used within DevS in-between two type aware > mediators, it can figure out the correct input output types by callling the > corresponding methods of the two adjacent mediators in the sequence. If it > cannot figure out the input/output types, the user will manually have to > specify the corresponding types. > > Thanks, > Jeewantha > > > On Fri, May 16, 2014 at 7:47 AM, Malaka Silva <mal...@wso2.com> wrote: > >> Hi, >> >> With related to connectors I guess main idea here is to have different >> connectors in a flow which can integrate with each other. I think recipes >> will definitely benefit from this. >> >> In the case of connectors both input and output will always be same. We >> can specific this in init method of the connector definition. >> >> >> On Tue, May 13, 2014 at 5:07 PM, Kasun Indrasiri <ka...@wso2.com> wrote: >> >>> Hi, >>> >>> We been working on the initial design of the type-aware mediator concept >>> for ESB. The main objective of this is to have an input and output type for >>> the mediators so that transformation mediators(such as DataMapper mediator) >>> can decide its input and output type dynamically. >>> >>> - One of the common use case of this is that data mapping between two >>> connectors operations . >>> >>> <twitter.search>.. input and output : json >>> <dm> ---> Deduce the input and output message type by inspecting >>> the successor and the predecessor mediators. >>> <sf.query> .. input and output : soap >>> >>> >>> - In scenarios such as PayloadFactory the user provides the input type >>> and the output type >>> >>> e.g : <pf> .. input - JSON, output - XML etc. >>> >>> >>> - Some mediators won't have an input or output type and they are >>> non-type aware : eg: send, property etc. >>> >>> - All connectors should have the supported message/media type as an >>> attribute and that should be the same as the original API. (If the backend >>> API is JSON then the connector's input and output types will be JSON). The >>> supported message type or media-type will be an attribute of a given >>> connector and we can specific that in component.xml(in connector archive) >>> of a specific connector. >>> >>> Taks list: >>> >>> Mediation Engine : >>> - Introduce inputType and outputType at abstract mediator level. >>> - Message flow verification based on input and output types. This >>> includes verification of connector invocations (call-templates for >>> connectors). >>> - Review/refactor mediators such as Payload factory to incorporate type >>> aware concept. >>> >>> Connectors : >>> - Introduce type concept in to connectors (new versions of existing >>> connectors) >>> - Connector invocation (call-template) deployment should verify input >>> and output types during the deployment time. >>> >>> We have started working on a poc on type-aware mediation concept and >>> please share your thoughts too. >>> >>> Thanks. >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/<http://wso2.com/about/team/malaka-silva/> >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Jeewantha Dharmaparakrama > Software Engineer; WSO2, Inc.; http://wso2.com/ > Phone : (+94) 774726790 > Skype : prasad.jeewantha > LinkedIn : http://www.linkedin.com/in/jeewanthad > Twitter: https://twitter.com/jeewamp > Blog: http://jeewanthad.blogspot.com/ > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
