Hi, SVN: http://svn.apache.org/repos/asf/incubator/yoko/trunk
Main site: http://incubator.apache.org/yoko/ You can find all the information in there... I will merge the soap-corba demo asap. - Balaji On 8/6/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Balaji, Is the code in JIRA or SVN or somewhere we can look at? thanks, dims 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... > > Thanks > > > Balaji > > > 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] > > > > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
