Dear Ant (and other Tuscany users):
First of all, thank you very much for your ample explication of the existing
possibilities.
Please, let me put my remarks and/or further questions within your response
text:
> Tuscany and SCA _DOES_ also apply to the presentation layer and
> provides various means of "SOAfication".
>
> There is a specification that defines how SCA can be used in a JEE web
> container. [...]
>
> There are two main approaches:
>
> 1) Have the web application presentation layer outside of the SCA
> domain and access the domain as a remote client calling domain
> services
> 2) Have the web application part of the SCA domain and use SCA
> assembly to connect the presentation layer to data access and biz
> logic services
>
> The main advantage of (2) is that it enables using the all the
> capabilities of SCA such as injection, declarative assembly, easy
> re-wiring etc.
It's precisely approach (2) I'm pretending to achieve.
> The main difference to the presentation layer code between using the
> two approaches is with how it gets hold of the services to use. Using
> approach (1) the presentation layer code needs to either:
>
> (1a) hardcode the protocol and endpoint of the service and invoke it
> using its own support for that protocol. For example if ZK natively
> supports JSON-RPC it could use that to invoke Tuscany/SCA services
> exposed with <binding.jsonrpc>
>
> (1b) if the ZK application is running locally to the SCA domain it can
> get hold of the Tuscany SCADomain or Node object and use the
> getService method to get an invocable proxy for the SCA services
If I would follow the more disadvantageous (static) approach (1), then solution
(1b) would hold in my case. But I'd prefer the more dynamic and
SCA-incorporated approach (2) over this more static one.
> Using approach (2) the presentation layer code needs to either:
>
> (2a) if the presentation layer code uses a web technology that has SCA
> integration then it simply uses SCA annotations in the presentation
> layer code and the Tuscany runtime will inject the required objects
Yes, this is the 1st possibility I'm aware of, using the SCA-supported JSF/JSP
technology with or without the Dojo Toolkit -- I'm looking for an *ajax-ified*
web presentation solution; Thus, this could be an equivalent alternative to my
mentioned ZK-based scenario.
I took ZK into a closer consideration because I'm already more confortable with
ZK as with Dojo, and IMHO it has a "nicer look" and a more abundant set of ui
components to choose from (at least at the time I did my last research on these
issues).
> (2b) if the presentation layer code web technology being used does not
> support native SCA integration then it needs to get hold of the SCA
> ComponentContext and manually look up the required objects
Unfortunately this is the case for ZK (see further below for a related
question, please).
> The main advantage of (2b) over (1b) is that it still provides support
> for the capabilities of SCA such as declaritive assembly, easy
> re-wiring etc.
>
> Option (2a) provides the cleanest approach but it requires specific
> Tuscany support the web toolkit being used. Tuscany provides this
> integration code for some common web technologies and toolkits like
> Servlets, JSP, JSF, Stripes, (and soon Wicket), and Tuscany's
> proprietary <implementation.widget>. Tuscany doesn't have any support
> for ZK, it would be fairly easy to write that support but we can't do
> it here at Apache Tuscany as the ZK license is GPL which is a problem
> license so Apache code can't use it directly. We could provide help if
> you are interested in writing SCA support in ZK, but we couldn't host
> that code within the Tuscany project itself.
For the case I would insist on ZK and therefore be obligated to write some
Tuscany "enhancements":
Can anyone of you provide -- or point me to -- the following information:
1. Which programmatic Tuscany resources (Tuscany components) would be involved?
2. What exactly would be the way to go?
3. Which analogous & existing "technology incorporation" could I look at, to
have a working example to study from?
(An enlisting of the relavant source code resources would be sufficient)
And last but not least a still open question:
4. Does anyone of you tried out the alleged ZK integration into Spring as
WebFlow app and running within a plain SCA scenario?
Is it really possible? And, could you please share your experiences with
this approach?
So, that's all for now.
Thanks a million for all your constructive hints in advance.
Best regards,
Florian
__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausländische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms
