concept for future magnolia (possibly 3.5) (MAGNOLIA-587)

[MAGNOLIA-589] Admin interface: XML-RPC vs SOAP Created: 31/Oct/05  Updated: 03/Dec/13  Resolved: 03/Dec/13

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Philipp Bärfuss Assignee: Unassigned
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:

 Description   

Here we discuss the framework we use for the new the admin interface implementation.



 Comments   
Comment by Kyle Gabhart [ 31/Oct/05 ]

First, I must mention my bias. I have extensive experience working with XML-RPC and feel very comfortable with that protocol. It is simple, straight-forward, and has an extremely mature user community. In fact, I even developed a J2ME implementation of the XML-RPC protocol 3 years ago as a part of Enhyrda's J2ME platform: http://kxmlrpc.objectweb.org/

That being said, I vote in favor of XML-RPC and the Prototype JavaScript library. My reasoning is as follows:

  • XML-RPC is a standard ( meeting of the core goals for Magnolia 3.0)
  • Prototype.js supports SOA better than DWR because it encodes data with XML-RPC which has a mature user community and dozens of implementations
  • DWR has better documentation, but seems to be targeted more at integrating with frameworks that we aren't using (Spring, Struts, Hibernate)
  • DWR is Java-specific, and although this seems like a good thing, I think that ulitmately it would limit us because we would need to integrate DWR's servlet controller architecture into our own rather than using Prototype which lets us define the server architecture
Comment by Philipp Bracher [ 02/Nov/05 ]

I support XML-RPC for the same reasons and concerning other discussions I would say that Sameer, Boris, Michael and Nicolas do so too.

If no one has other arguments agains this new architecture model based on XML-RPC I look at this part as fixet.

Comment by Andreas Brenk [ 02/Nov/05 ]

I'd like to propose using SOAP Document/Literal style instead of XML-RPC.

This should provide some more flexibility than with a pure RPC based approach (wether it is XML-RPC or SOAP RPC style).

For example it would allow more than one command to be sent to the server in a single request.

Also I think that SOAP doc/lit is "the most enterprise" way to go as it allows extension using one of the many WS-* standards. This would allow developers to better integrate Magnolia into the enterprise wide SOA infrastructure using standard WS-* extensions as needed. (WS-ReliableMessaging, WS-Security, etc.)

Another point is that the interface of the service can be formally described using WSDL so that IDEs can assist in the usage of the Magnolia provided services by other applications. Apart from providing the formal specification of the service interface the WSDL can also integrate additional developer documentation using embedded wsdl:documentation tags.

Simple usage should not be any more complicated than XML-RPC.

Some links to interesting articles:

SOAP? Why SOAP? (example of a simple SOAP doc/lit request)
http://oompahzing.blogspot.com/2005/10/soap-why-soap.html

Call SOAP Web services with AJAX, Part 1: Build the Web services client (overview of AJAX and SOAP)
http://www-128.ibm.com/developerworks/webservices/library/ws-wsajax/

See item 1) of the important items for a nice idea how to send additional data to the client
http://oompahzing.blogspot.com/2005/10/why-another-server.html

Secure, Reliable, Transacted Web Services (overview of all IBM backed WS-* standards)
http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/

Comment by Philipp Bracher [ 02/Nov/05 ]

Reading the first link (Why SOAP?) I noted:

.. "BTW. Parsing large XML responses in a browser can be very slow. Our server lets you post requests in SOAP, and get them back in JSON. The client then just evals the JSON."...

I'm not used to SOAP. Would this be a possibility:

  • we use a formal SOAP body for the call (as described in the second link)
  • the message is provided as an XML-RPC message (since there exist js to xml-message converters)
  • the client can decide if he likes the retured message in a json or xml-rpc-message format (for both are converters available)
Comment by Kyle Gabhart [ 02/Nov/05 ]

Parsing large XML responses in a browser can, in fact, be very slow, this is why I thought we might be leaning toward XML-RPC as its XML structure is much less complex than SOAP's. That having been said, if these challenges have been overcome and SOAP is being handled performantly in the browser than I certainly concur with Andreas. There is no question that SOAP has broader acceptance in the SOA community and has more standards around it. It is unquestionably "enterprise-grade" with a host of supporting technologies defined to support it. The real value with SOAP, however, is for external communication with parties that you do not have a formal relationship. My understanding of how we would use this is simply for internal communication between components within the Magnolia server. That being the case, SOAP would seem to provide a lot of additional overhead for very little return.

To address your questions more specifically Phillip, I don't see the value in providing a buffet of options for the user and supporting conversions between XML formats. I've gone down this path before and no matter how simple and straightforward a conversion may appear, you will spend countless hours working out all of the exception cases where the conversion does not go smoothly. XML is a very flexible technology. Sometimes....maybe too flexible.

I think that we need to decide on a protocol (SOAP or XML-RPC) and corresponding JS library (DWR, prototype, etc.) and make sure that we choose each one because they are the right answer for Magnolia. Just as Spring was rejected as a framework technology for Magnolia 3 because it didn't fit with the core philosophy and direction of the product, I would caution choosing SOAP simply because of its momentum and popuarlity. If we truly want the AdminInterface to be as interoperable as possible and communicate with external parties that are non-magnolia components, then SOAP may well be the right answer. If, on the other hand, we simply want magnolia components talking to other magnolia components (or external components using a magnolia component as a proxy), then I would lean more toward XML-RPC.

Comment by Andreas Brenk [ 02/Nov/05 ]

We have to differentiate between SOAP Document-style and SOAP RPC-style. SOAP in its original RPC-style had many disadvantages compared to the much lighterweight XML-RPC (basically it is XML-RPC plus a whole bunch of namespaces. See http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index.html for some examples of the different SOAP styles).

But if we compare SOAP Document-style and XML-RPC I think SOAP would nearly always result in much smaller requests and responses.

Let's compare the (slightly modified) SOAP example from my previous comment (http://oompahzing.blogspot.com/2005/10/soap-why-soap.html) with its equivalent in XML-RPC.

SOAP:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<CreateFolderRequest name="example"/>
</soap:Body>
</soap:Envelope>

XML-RPC:
<methodCall>
<methodName>createFolder</methodName>
<params>
<param>
<value>
<string>example</string>
</value>
</param>
</params>
</methodCall>

The difference in size gets even more noticable with more complex interactions. RPC-style always has the disadvantage of being verbose compared to Document-style.

Comment by Kyle Gabhart [ 02/Nov/05 ]

I am fully-aware of the virtues of Doc-style vs RPC-style SOAP encoding. In fact, many vendors and SOAP frameworks are dropping support for RPC-style entirely, especially with the advent of 'wrapped doc-literal' as advocated by the .NET framework and the Apache Axis team. This approach actually lets you have the best of both worlds, sending DOC-style messages in an RPC-ish sort of way.

It is tempting to look at the XML structures and assume that the verbosity of XML-RPC means a performance hit, but this simply is not the case. With SOAP there is a lot more to the picture than just how many characters are used to represent an element. What allows SOAP messages to be so thin is that there is a huge amount of overhead processing and supporting definitions that describe how to handle the namespacing, datatyping, validation, etc.

1) The SOAP spec is much more complex. The SOAP spec has a 47 page primer (if you were to print it out) and the actual spec is broken into 2 parts with a total of 86 pages. Additionally, SOAP depends upon the XML Schema spec to handle datatype encoding. This spec has a 72 page primer and the actual spec is broken into 2 parts with a total of 314 pages. I didn't even bother looking at the complexity of the XML Namespacing specfication which SOAP also relies upon. The XML-RPC spec if printed covers a whopping 3 pages.

2) SOAP datatyping is much more complicated than XML-RPC. Through XML Schema definitions, SOAP supports 40 pre-defined datatypes and the capability to define a whole range of custom types. XML-RPC defines 8 types: 6 simple types, structs, and arrays.

Although the analysis is a bit outdated, Kate Rhodes does a pretty good job of comparing XML-RPC and SOAP in this BLOG: http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm

Again, I don't honestly care which direction we choose, I just want to make sure that the team goes into this with their eyes open and chooses the right technologies for the right reasons.

Comment by Andreas Brenk [ 03/Nov/05 ]

Kyle, I'm aware of your published work and didn't want to educate specifically you. I just wanted to make sure that readers not as familiar with SOAP's intricacies as you become aware that the criticism that SOAP rpc/enc has received does mostly not apply to SOAP doc/lit.

I could well live with XML-RPC but think that SOAP should be the preferred choice if we want to make sure that Magnolia gets the "Enterprise friendly architecture" that Philipp's paper states. Well, we both have taken our stand regarding this question.

Comment by Philipp Bracher [ 03/Nov/05 ]

Since DWR is not longer an option and the discussion is turning in this direction I changed the title.

Comment by Kyle Gabhart [ 03/Nov/05 ]

Understood Andreas, I took no offense. I think we've provided ample information for the core team to consider. At this point, we simply need to sit back and see what direction makes most sense to obinary and the core magnolia team. Thanks for your valued input on this.

Comment by Philipp Bracher [ 03/Nov/05 ]

Thank you both for pointing out this two solutions. It is a very tricky decision since both goals a) enterprise capabilities and b) simplicity can be mapped to these two solutions. Even worser looking at the goal to use standards. Then one could tend to say that SOAP and WDSL has the better cards.

From my point of view we should follow this priorities
1. simplicity
2. enterprise capabilities
3. standard

I feel that magnolias success will depend more on the simplicity than on having the most enterprise enabled solution. The same I would say about standards. There are many examples of overloaded standards having first a big hype and then mainly caused big costs.

This implies that I tend to XML-RPC which I would call web developer friendly. Still the door is open for SOAP.

Comment by Alexandru Popescu [ 06/Nov/05 ]

Most probably I am missing something in this whole discussion . While I can see some benefit in using xmlrpc over dwr (but I am still missing the scenarios - maybe somebody can give some hints here), the part that I am completely missing is why would we need to do things more difficult/complex. Probably the arguments should be spec based vs non-spec based and some performance comparisons.

./alex

.w( the_mindstorm )p.

Comment by Alexandru Popescu [ 16/Nov/05 ]

A very interesting discussion about almost the same steps is taking place here: http://article.gmane.org/gmane.comp.java.dwr.user/420.

./alex

.w( the_mindstorm )p.

Comment by Philipp Bracher [ 21/Nov/05 ]

After some days off, I'm back again. The reason to use xml-rpc instead of dwr is the following:

  • dwr is only available for javascript enabled browsers (for xml-rpc exists a lot of implementations)
  • xml-rpc allows flash clients (nicolas is currently working on such a thing)
  • there are not thousends of services called from the client (about 15). Will say the overhead is not that big.
  • XML-RPC is from my point of view easier to understand than DWR
Comment by Philipp Bracher [ 21/Nov/05 ]

I like this statement: http://article.gmane.org/gmane.comp.java.dwr.user/424

...' In our application, we write services as POJOs, and then simply remote
them via both Apache Axis (SOAP) and DWR. So we have "reusable
standards-based web services" that make the architects happy... while we
can still use DWR's efficient JS-based protocol for our AJAX needs. In
my opinion, it really is the best of both worlds.' ...

This could work for us too!

Comment by Alexandru Popescu [ 22/Nov/05 ]

IMO this should be the solution Magnolia is going. In this way it will be able to beneficiate of the simplicity of using DWR in the web and also offering SOAP for other applications.

./alex

.w( the_mindstorm )p.

ps: Philipp, I thought you will like the thread .

Comment by Andreas Brenk [ 23/Nov/05 ]

I agree.

Comment by Philipp Bracher [ 09/Dec/05 ]

I stated to refactore the tree (for some special paragraph) and I like this approach.

  • we make service POJOs simplified to use with DWR, Axis, XML-RPC
  • the services are using the 'real' model. We do NOT provide the model directly as service

I think this separation makes sense.

Comment by Philipp Bärfuss [ 03/Dec/13 ]

We use now Vaadin and plain REST for content exchange.

Generated at Mon Feb 12 03:18:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.