Hi Sanjiva,
>That's ABSOLUTELY possible. That's possible right now by writing a
>mediator. Once we finish the Axis2/WSIF stuff it'll be possible dirt
>simply from Synapse.
>mediator. Once we finish the Axis2/WSIF stuff it'll be possible dirt
>simply from Synapse.
It would be helpful if you could elaborate on the point above. It would be helpful to know how you see it working with the WSIF stuff... What does WSIF provide for synapse to accomplish the soap-corba bridge? I am interested because thats the problem we are trying to solve with yoko.
Thanks
Balaji
On 8/2/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Wed, 2006-08-02 at 14:37 -0400, Hadrian Zbarcea wrote:
>
> Coming back, we now have a legacy corba server, and we have an xml
> schema that defines the types used by the corba app and the wsdl that
> describes the interface and corba binding that deals with the
> marshaling and the service that holds the ior address of the corba
> server. One could write a pure web services app using types generated
> from the xml schema/wsdl and send the invocation down the ws stack.
> When it gets to the corba binding the in memory java objects are
> marshalled into corba streams which are sent over iiop to the
> server... and then response comes back the same way. So having a
> corba/iiop binding should be absolutely transparent to the user and as
> easy as doing soap/http or xml/jms.
Cool. Does Yoko also offer a way to directly marshall into IIOP, using a
DII type interface? That is, can we take an XML document and an IDL
document and serialize the XML doc into IIOP according to the IDL?
I assume that should be possible (can't think of any reason why its not
possible!). Once we have that, combining that work with the effort to
bring in WSIF-like function to Axis2 (which is going well) then we'll
have the ability to take a message context and invoke a CORBA object
directly.
> One implementation detail that complicates things today a bit is that
> synapse is by design too tightly coupled to SOAP. Therefore the corba
> message must be wrapped in a soap envelope to put it in a synapse
> message context. Ideally we would refactor the MessageContext to
> remove the SOAP related api (I can think of a couple ways of achieving
> that) and make it more generic. I am curious actually what others
> think about this. There are other issues related to uses of
> ws-addressing references etc. but all solvable.
Synapse has the same design principle as Axis2: Its about processing XML
messages. The SOAP nature is abstract really .. we have a model of the
SOAP Infoset but that is virtual. As long as the message shows up as an
XML Infoset then its fine.
Synapse is not meant to solve every problem in the world .. the
advantage of Axis2 and Synapse is that it takes a hard position saying
the world is all about XML and SOAP (Infosets). All other stuff is
second class .. and that's what gives it the simplicity and flexibility
and performance. If we take that out we lose everything and we become
something crappy like a JBI implementation ;-). Both Paul and I've been
there done that with a data format independent message representation
and all that jazz and the reality is that stuff doesn't work beyond
simple cases. JBI (and SCA) are both busted in that respect from my
point of view.
So in short, I'm totally against losing the XML and SOAP centric nature
of Synapse (or Axis2).
> I understand Balaji is putting together a bank demo that shows the
> interaction between soap and corba with no glue code required.
That's ABSOLUTELY possible. That's possible right now by writing a
mediator. Once we finish the Axis2/WSIF stuff it'll be possible dirt
simply from Synapse.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
