[
http://jira.nuxeo.org/browse/NXP-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29649
]
Radu Darlea commented on NXP-1720:
----------------------------------
Excerpts from previous emails regarding the overall WS JAXWS solution:
"Soapify Nuxeo5 :
================
Overview :
----------
As you could have seen on new Nuxeo Web site, Nuxeo5 is now marketed as a stack
of services.
This is mainly true thanks to the Runtime Service / EJB3 Facade system. But
there is still a big lack concerning Web Services : for now we mainly have only
small webservices that were created for specific use cases (LiveEdit and
external indexing).
Even if I am not really convinced by the buzz about WebServices and SOA, we
must admit that :
- it can be usefull when integrating Nuxeo5 with exogene technologies
- it can be usefull to sell Nuxeo5 to client that where told that WebServices
and SOA is a "must have"
These are the reasons why we must work on Soapifying Nuxeo5 for next release.
Target :
--------
The target is simply to be able to say that Nuxeo5 service stack is available
via POJO / EJB3 remoting and SOAP without having to lie :) So technically we
must expose at least a big part of the service API via SOAP.
Limitations and problems to solve
=================================
Change underliying WS framework :
---------------------------------
Nuxeo WebServices currently uses AXIS. This framework has shown it's limit in
termes of compatibility, clean WSDL generation and flexibility. We must align
to a more recent framework based on JAX-WS (like JBossWS 2). Outside of the
fact that Axis and JAX-RPC sucks, JAX-WS is the standard and seems more adpated
to do direct XML manipulation for complexes objects.
Stateless vs Stalefull
----------------------
Nuxeo Services are mostly stateful :
- because they need an authentication context
- because they sometime maintain some state data
Because of that most EJB facade are statefull Bean and statefull beans can not
be used to generate WebServices.
O/X Mapping
-----------
Nuxeo API contains a lot of parameters that are not simple types. Porting this
API to WS means Object/XML mapping. JAX-WS hadles this via JAXB, but I doubt of
the flexibility of this mapping (probably even less flexible that the current
O/R mapper).
This can be a problem, especailly for objects in the API that are not pure
structure : for example a DocumentModel contains a lot of "client side" code
and can not be reduced to a XML structure ...
Requirements :
==============
Real compatibility :
--------------------
Partability is the promiss of WS, if we decide to go that way, let's make it
real. We need to a least be able to test our API from : JAVA / .Net / PHP / ???
As less as possibible of boring / mapping code :
------------------------------------------------
We already have the EJB facade that in most cases are stupid code in front of
the Runtime Implementation. If we can avoid to have an other layer of stupid
mapping on top of facade, it would be really great.
Global coverage of Nuxeo API :
------------------------------
WS stack needs to provide the basic API for doing each standard operation in
Nuxeo :
- browse the repository
- retrieve / create / edit / delete a document
- retrieve / create / edit / delete a user / group
- start a wf
- put / read relations between documents
- ..."
"Moreover, over the time the WS standards evolved to higher versions. If we go
with JAX-WS we imply the compatibility with a pack of extensions. And most
probable we'll use them. Most notable are:
* JAX-WS 2.0/2.1 (JSR 224)
* WS-I Simple SOAP Binding Profile 1.0
* WS-Addressing 1.0 - Core, SOAP Binding, WSDL Binding
For instance, WS-Addressing is require more than SOAP understanding.
But being compatible with older versions, we have even more work to do.
I think going with older implementations, like JAX-RPC, we'll be larger
compatible (accepting clients with reduced capabilities, backward compatibility
with the already deployed WS in Nuxeo), but harder work.
Going with newer standards (namely JAX-WS and the implementation JBossWS 2.*)
we are a step ahead, but the older WS are not working, nor clients based on
previous WS frameworks. Do we care about them?
[...]
It looks like using WS-Addressing makes possible use of stateful beans. Not
sure yet, I will test, but AFAIK it is addressing this issue in purpose. So
yes, stateful beans can be wrapped in a WS manner.
WS-Addressing is my first thing to look for. I am curios if and how it is
working with stateful beans.
See http://tssblog.blogs.techtarget.com/2007/04/27/stateful-soap-and-beans/";
"Yes, we care about interoperability with client SOAP libraries. This is the
selling point of using SOAP in the first place (besides pure marketing hype).
We need ideally to support at least:
- the .NET libraries
- the most popular (if not all) libraries listed here:
http://www.infoq.com/articles/os-ws-stacks-background
- at least the most popular library for PHP (?), Python (ZSI), Perl
(SOAP::lite), Ruby (soap4r), Groovy (whose SOAP lib is based on XFire), using
the dynamic nature of these languages (i.e. using "dynamic proxies" and not
stub code generation from WSDL)."
"Well, I am not sure it exists definitive and certain answer. Although the WS
was created to enhance interoperability between different platforms, the
proliferation of WS standards (SOAP 1.0, 1.1, 1.2, WSDL 1.0, 2.0, WS-*, JSR109,
JSR181, MTOM, etc) leaded to severe issues in connecting clients with different
servers. For instance, MS asks both server and client being WSE3.0 when at
least one of them is built on WSE3.0.
There was a common project between Sun and MS
(http://java.sun.com/developer/technicalArticles/glassfish/ProjectTango/)
intended to prove the interoperability between .Net and JAX-WS. Specifically
about .Net client, MS seems to be most advanced in WS technology, supporting
lot of the standards and even enhancing their framework with proprietary code
(WSE). About compatibility, they claim they understands most of WS-*:
http://msdn2.microsoft.com/en-us/library/system.web.services.description.soapextensionreflector.aspx
The others clients have no common base (except maybe SOAP 1.1 and WSDL 1.0).
Restricting the development to these only features would be painful. Not sure
if doable in a reasonable amount of time, or easy maintainable. I will dig
further but I think we can be sure of compatibility only after testing specific
implementation. We should try to restrict WS work to simple feature as much as
we can in order to obtain simpler API.
Also, we have to consider what JBoss (and maybe another vendor AS) supports and
in what extent. For instance, Axis can be deployed in JBoss, but it has no
advantage of using EJB or anything else. JBoss entitles native stack and Sun
Metro only as JAX-WS supported stacks. "
"For instance, here is some Python code that should work (and currently
doesn't):
--
#!/usr/bin/python
WSDL_URI = 'http://localhost:8080/nuxeo-platform-5/NuxeoRemotingBean?WSDL'
import SOAPpy, getpass, datetime
nuxeo = SOAPpy.WSDL.Proxy(WSDL_URI)
session_id = nuxeo.connect("Administrator", "Administrator")
--
Or some Ruby code:
--
#!/opt/local/bin/ruby
require 'soap/wsdlDriver'
WSDL_URI = 'http://localhost:8080/nuxeo-platform-5/NuxeoRemotingBean?WSDL'
# connect to RAA and create SOAP proxy object
nuxeo = SOAP::WSDLDriverFactory.new(WSDL_URI).create_rpc_driver
print nuxeo.connect('Administrator', 'Administrator')
--
Or some Groovy code:
--
import groovy.net.soap.SoapClient
def proxy = new
SoapClient("http://localhost:8080/nuxeo-platform-5/NuxeoRemotingBean?WSDL";)
println proxy.connect("Administrator", "Administrator")
--
Or some Perl code:
--
#!/opt/local/bin/perl
use SOAP::Lite;
$WSDL = 'http://localhost:8080/nuxeo-platform-5/NuxeoRemotingBean?WSDL';
print SOAP::Lite
-> service($WSDL)
-> connect('Administrator', 'Administrator')
-> result;
print "\n";
--
None of them currently works."
"So the plan is to focus on a clean and lean implementation using JAX-WS (and
WS-I Basic Profile). All WS stacks implementations are currently standardizing
on this, as far as I can see. And we cannot restrict to SOAP 1.1 and WSDL 1.0.
Or we'd better only offer a pure REST / XML interface and forget about WS-*.
All open source java WS stacks claims to standardize on JAX-WS. So let's take
this as the hypothesis and let them do the work (moreover, Metro seems to be a
very good ).
Our primary focus should be .NET (+ WSE 3.0) since it's what our customers are
asking for. I would like to see in the near future automatic test suite using
.NET client (alongside SOAP UI tests for Java) to ensure the compatiblility
with .NET (we could also provide .NET reader/writers for our XML doc model,
later).
Moreover, switching to JAX-WS RI (aka Metro) we should be more compliant with
all stacks as Metro guys seem to make big efforts to be compatible with other
stacks.
For dynamic language lacking of a robust WS stack, we can offer the REST
interface (maybe improving it to offer a more exhaustive API). And anyway,
Axis2 seems on the way to offer native bindings for those languages. Or we can
leverage Runtime's scripting features to use those.
On the WS side, MTOM is a must since one of the main use cases for our web
services will be binary transferts. I think also taht WSDL 2.0 is very
interesting since it allows to bind on HTTP verbs (to prepare for the REST /
SOAP convergence) but we'll have to wait that Metro supports it. "
"It is very possible that WS-Addressing helps a lot in emulating sessions and
to connect to stateful beans (didn't try it, so not 100% sure). Should it be
discarded? Of course there are other methodology which could do the trick,
probably in a dirtier way.
Also, not sure that Metro is more suitable than JBossWS, regarding AS
integration. In the end, JBossWS relies on Metro. And to decide what standards
are required is a matter of what is used in Nuxeo code rather than what
implementation is used. But I agree that Metro is more likely "standard" than
JBossWS, and also adopting a different AS would be easier. "
"course not! :-)
If WS-Adressing does the job, let's go for it (BTW, I see this name a lot and
would appreciate a summary to understand what it actually does :-) .
For Metro and JBossWS, I do agree on going with JBossWS if we can transparently
(or almost) switch to a pure Metro implementation (please keep in mind that we
will need to support other app servers such as Glassfish). But if JBossWS is
implementing standard, it should not cause problems. Just keep it in mind,
cause we'll need this.
To summarize please start on JAX-WS / Metro (I know that JBossWS gives you the
abstraction) and design a nice WS implementation for Nuxeo. ;-)"
"1. jbossws-native-2.0.1.GA is extremely easy to install and use. I just
dropped it in jboss AS and instantly the WSAudit was deployed and displayed in
the Web interface. It was no need for any other configuration or work on the
code.
2. Metro 1.0 is in fact a bundle containing JAXB RI, JAX-WS RI, SAAJ RI, SJSXP,
and WSIT. The key components are JAX-WS RI which provides the tools for
generating and managing a WS complying with JAX-WS 2.1 (JAX-WS - RI 2.1.2), the
WSIT wrapper implementing the interoperability with WFC (not sure yet if this
i14y would also keep the i14y with the other OpenSource clients) and JAXB.
It has to be installed on jboss and, surprise, it doesn't work right away with
our code. The WS code has to be "apted" with apt tool and the resulted files to
be packaged together with special config files in order to make them work.
Also, Metro requires Tomcat, which is not the case of jbossws.
At a first inspection, I found that:
- Metro is implementing a sensibly larger number of standards than jbossws
- Metro is requiring updating the Nuxeo build system. I don't think it is very
complicated, esp. if we can easily add apt as an ant task. But it took me 2
days to manage to have WSAudit service deployed :( .
- Metro is adhering to the new jax-ws standard, which replace the older jax-rpc
approach. Probably this will require some minor changes in the services already
deployed.
- Developing on Metro binds us to Tomcat, but not to JBoss, so switching on
different AS is easy as long as Tomcat is preserved. OTOH, jbossws decouples
from Tomcat, so if AS is preserved but we need to change WC going with jbossws
is the right thing.
- WSIT implements i14y with WFC because it specially formates the WSDL for the
MS clients usage."
"The solution I am intending to develop is:
- I created a new package (project) to collect all the WS
- there is a NuxeoMainEntrancePoint stateless bean which deals with connecting
and creating the ERP for the actual service
- every service is a stateful bean.
The workflow is:
Server side: for every service there is a method
NuxeoMainEntrancePoint.access<ServiceName>(credentials) which returns an ERP to
the actual implementation. The service implementation is a simple bean class
prefixed with @Stateful @WebService @Addressing. For the rest (session,
managing the bean, creating the URI, etc) jaxws stack will take care.
Client side: the client calls access<ServiceName>(credentials) on the server
and uses the resulted interface to carry on all actions."
> Implement LiveEdit Web Service on top of JAXWS
> ----------------------------------------------
>
> Key: NXP-1720
> URL: http://jira.nuxeo.org/browse/NXP-1720
> Project: Nuxeo Enterprise Platform 5
> Issue Type: New Feature
> Affects Versions: 5.2
> Reporter: Radu Darlea
> Assignee: Radu Darlea
> Fix For: 5.2
>
>
> Implement the new LiveEdit Web Service.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
