Hi Guillaume,
I'm rethinking of these discuss related to WSDL support into components
as I'm working on RMI and Exec components this morning.
As I have a little more experience, let me add some comment to get team
feedback.
Guillaume Nodet wrote:
On Sun, Feb 1, 2009 at 11:41, Jean-Baptiste Onofré <[email protected]> wrote:
In fact, it's in two parts :
1/ using a WSDL endpoint property to expose a WSDL can be interesting to use a
BC
directly with a SE supporting WSDL (for example, directly use a HTTP publishing
a
smpp WSDL).
There are multiple things here. The first one is to add a property so
that the endpoint exposes a WSDL to the NMR.
The second one is to expose those WSDLs to the outside world (i.e.
through HTTP for example). The third one, which I'm not clear if
that's what you are suggesting, is to make all the BC support SOAP.
Let's discuss those points.
#1 for endpoints not supporting soap, it makes sense to be able to
describe those using WSDL nonetheless when it makes sense. It should
just be about adding a property to those endpoints and let the user
specify its own abstract WSDL to describe the endpoint (this is
already done in a number of EIP patterns for example).
Yes, it's exactly the purpose. Basicly, I think that the WSDL can be
marshaler related. The WSDL can describe the operation (with arguments)
supported by the marshaler.
The purpose is to define a manner to get information about message
content and operation applied on the command into the endpoint descriptor.
#2 I'm not sure about that one. Services exposed in the NMR are not
necessarily available for external clients (especially if no BC
consumer endpoint has been defined to target a given service).
Furthermore, if we really want to expose those WSDLs (or at least the
one of the BCs consumers which can be targetted by clients), we need
those WSDLs contain the needed informations for the clients to be able
to use those. This means that we have to define WSDL extensions for
those protocols I suppose (we still have none for JMS, though a
standard JMS extension is being worked on somewhere).
Agreed, but it means that a "non-SOAP" component (such as exec, file,
etc) can't be facaded directly using a HTTP or CXF-BC component. In this
case, the user needs to add a component between the HTTP component and
the Exec one for example to transform the incoming SOAP envelope into a
valid message for the Exec endpoint.
If we can add (at least a basic) SOAP support into all BC, the user can
expose quickly basic services.
AFAIK, OpenESB works like this: you define a WSDL for the component
attribute (like in the xbean.xml) and define the endpoint behavior.
#3 I don't have any problems with all BCs supporting SOAP. I'm just
not sure if there is any real use of SOAP over XMPP, SNMP or SMPP.
2/ currently, BC uses "internal" format. For example, for the SMPP component,
Lars has defined a XML format looking like this :
<message>
<source>+336123456</source>
<destination>+336654321</destination>
<ton>INTERNATIONAL</ton>
<npi>NATIONAL</npi>
<text>The SMS content</text>
</message>
If I need to use the SMPP, another SU must "format" the target message (the
NormalizedMessage content) into the format expected by the SMPP one.
Maybe it can be interesting to define a XSD (BC global or by components group)
and linked util class to normalize the format of messages content. Or, in place
of a XSD, define a kind of standard WSDL for BCs.
I hope I'm clear :)
I'm not sure how we can easily define a standard xml schema for all
protocols. Each protocol has its own informations that it needs to be
able to send the request. Wdyt ?
Yes, you have right. But maybe each component can define its own
XSD/WSDL. The user can construct a valid incoming message to this BC
(using wsdl2java for example).
All feedback are welcome.
Regards
JB
Maybe this kind of stuff already exists and, if it's the case, accept my
apologize :)
Regards
JB
--
Jean-Baptiste Onofré
[email protected]
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
On Tue 27/01/09 13:07, "Guillaume Nodet" [email protected] wrote:
Are you thinking about just exposing a WSDL service, or more like full
soap support on file / ftp and other protocols ?
On Mon, Jan 26, 2009 at 13:17, <[email protected]
et> wrote:
Hi all,
Implementing the SMPP component, I have think about
the WSDL support.
Currently, some binding components don't support
WSDL (the endpoint descriptor is empty). It's the case for file, ftp, xmpp
and smpp components for
example.
Adding a WSDL property on these endpoints can be
great and we will be able to store a SOAP envlope in a flat file (for
example) and send directly to
a WSDL compliant service engine (such as
CXF-SE).
What do you think about this ?
Regards
JB
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Jean-Baptiste Onofré
---------------------------------
HomePage
http://www.nanthrax.net
---------------------------------
Contacts
[email protected]
[email protected]
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
