I too agree that the main point (SOAP-CORBA) in discussion has been somewhat lost due to the new discussion on synapse architecture.
Can you guys start it off in a different thread :-)
Balaji, Once your demo is done can you provide us with an example on how the SOAP types are mapped to the CORBA types and what needs to be done in order to use yoko.
I guess there is some interest at doing this both from synapse as well as axis2 side.So if u can come up with the above then I guess the axis2/synapse devs can start thrashing out the ideas on how we can leverage it.
Regards,
Rajith
On 8/5/06, Balaji Ravi <[EMAIL PROTECTED]> wrote:
Hi,I think this thread has been diverted from the issue of what needs to be done to accomplish the soap-corba bridge... What should be done in synapse to do this? I had asked the question before and i am still waiting for a definitive answer...As promised, I have a demo working right now which uses the celtix router to route the soap call to the corba endpoint... I will be merging it to yoko early next week...I want to know how synapse can make use of yoko...Note: Please include yoko-dev when replying...
ThanksBalaji
On 8/4/06, Sanjiva Weerawarana <[EMAIL PROTECTED] > wrote:On Fri, 2006-08-04 at 12:28 -0400, Hadrian Zbarcea wrote:
> I am afraid you're right. I suspect that what we see differently is
> the scope and the effort required. I assume you also agree then that
> the usefulness of Synapse for systems other than soap (such as corba)
> will be serverly limited because the mapping must be done somehow,
> somewhere.
Yes but that's ok by definition .. Synapse isn't trying to be that.
I don't think its impossible at all to support bridging to CORBA
endpoints with Synapse. All it means is that the conversion happens at
the fringes of Synapse and not inside it. Inside we assume the world is
entirely the big ugly world of SOAP.
> I see in Synapse a lot of potential for being used for non SOAP and
> not even WS based systems, just XML document based systems. My views
> were influenced a lot by the fact that, from what I see, most of the
> mediators already implemented do not actually care about the nature of
> the message. I therefore assumed that if Synapse could be refactored
> in a core that is not SOAP aware and other (pluggable) components that
> are SOAP (or something else) aware, this potential could be better
> realized. Otherwise Synapse will probably do a great job at covering
> just the niche it was originally intended for.
I'm fine with refining the mediators to make the core XML payload
natively visible to the user (for example I'd like the default xpath
context to be be /soap:Envelope/s:Body/*[1]). However, at the underlying
Java programming model level I'm absolutely with Paul that the data
that's given to the mediator must be the full SOAP aware message
context.
Otherwise simple stuff like "enableRM" become impossible.
> I guess it is up to you now to decide if you want to explore this
> avenue or, based on your previous experience, you might consider it a
> futile endeavour. Personally I know it's feasible after spending a
> couple of weeks trying it out. If we are to continue this debate, I
> think we should start a fresh thread.
With Synapse we're trying to say that the primary exposure of Synapse to
users is via the rules, not thru Java code. In that world, can you
explain what exactly you'd change?
BTW I still owe you a response to the other mail .. started it a few
times but didn't finish :(.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
