Hi Paul,
We've integrated several backend services that sound similar to what you are
describing.
We have the following general pattern:
- We generate a AXIS2 SOAP client from the WSDL description of the
web-services. We insist on a clean WSDL + Schema, so there are no issues with
client generation.
- The generated client provides a set of POJOs that will be very convenient,
more on that later, as well as the Bindings and Stub classes that can be used
to call the service
- We then create one or more magnolia "Model-Classes". Model-Classes are linked
to a template, area or component, and provide additional processing
capabilities for the template. Normally, we use the "execute()" method of the
model to call the web-service methods. We keep the response object in the model
for later use by the template.
- The model has "rendering" scope, i.e. each time your template/area/component
is rendered, a new model is instantiated and its execute method is called. The
model will automagically receive the values from GET or POST parameters in the
request, which you can then use when calling the web-service.
- When rendering, we provide getXXX() getter methods in our model that provide
access to the POJOs from the web-service as needed. Thanks to Freemarker's
BeanWrapper, you can access your data fairly easily from the template, e.g.:
${model.personData.officeLocation.doorNumber}
So it's not hard to do, in the end. The Axis-generated POJOs make it very quick
to work with the web-services from the template. The model is really just a
thin layer to call the web-service and pass back the data.
Some points to watch for:
- If your web-service exposes sensitive information, or provides much more
functionality than needed for the task, it might be better to implement a
wrapper-layer at some level, to prevent any "leakage" of sensitive information.
While in theory of course you only get to see what you ask for in the template,
programmers make mistakes and it's safer if magnolia never gets the information
it doesn't need.
- Since you are calling the web-service synchronously from the model during
rendering, the web-service should be sufficiently speedy, and you should
structure the web-service so that all the information for a given page-render
can be retrieved in one SOAP call. If you need 6 SOAP calls for one
page-render, the latencies will add up, and the page will be slooow...
For you, the "login" will be one of the points you need to think about. Will
you perform a login in magnolia, using, for example, the PUR module? I think it
depends a bit on where you plan to keep your "state" - will you need a session
for the user in magnolia? One solution that could work stateless in magnolia
would be to set a cookie with an authorization token for the web-service, and
use this cookie value whenever web-service calls are made, or something like
that...
Regards from Vienna,
Richard
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]
Im Auftrag von Paul Shuttlewood (via Magnolia Forums)
Gesendet: Dienstag, 31. Juli 2012 08:51
An: Magnolia User List
Betreff: [magnolia-user] Re: How to design Magnolia to retrieve/set external
data
Hi Gavan,
Our self service system has an existing set of web services that cover the
whole the range of login/register/retrieve/set of person details.
I'm half expecting to define a new set of interfaces for the person data so
that the CMS is not tighly coupled to the existing web services. Then develop a
middle man module that would be able to call the web services and translate the
returned objects into the objects CMS is aware of then. Then the display of the
objects is done within CMS.
Paul
--
Context is everything:
http://forum.magnolia-cms.com/forum/thread.html?threadId=2e16ec5c-2be3-4d9a-b79d-f6df9f2bc0bd
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
