Simon Laws wrote:
On 9/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I checked in a version of the Store sample described in the Getting
Started document a while ago.
I'd like to describe a few thoughts on how to improve the sample with
small changes to the sample itself and some improvements to the
implementation.resource extension and how it integrates with Web
2.0-friendly bindings.
The current Store sample looks like this:
store.composite
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
xmlns:s="http://store";
name="store">
<component name="ufs">
<t:implementation.resource location="ufservices"/>
<service name="Resource">
<t:binding.http/>
</service>
</component>
<component name="Catalog">
<implementation.java class="services.CatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<t:binding.jsonrpc/>
</service>
<reference name="currencyConverter"
target="CurrencyConverter"/>
</component>
<component name="ShoppingCart">
<implementation.java class="services.ShoppingCartImpl"/>
<service name="Collection">
<t:binding.atom/>
</service>
</component>
<component name="CurrencyConverter">
<implementation.java class="services.CurrencyConverterImpl"/>
</component>
</composite>
store.html
<html>
<head>
<title>Store</title>
<script type="text/javascript" src="binding-atom.js"></script>
<script type="text/javascript" src="binding-jsonrpc.js"></script>
<script language="JavaScript">
//Reference
catalog = (new JSONRpcClient("../Catalog/")).Catalog;
//Reference
shoppingCart = new AtomClient("../ShoppingCart/");
We can see that the Catalog and ShoppingCart services offered to the
Store client are properly modeled and configured with <binding.jsonrpc>
and <binding.atom>. However the Composite does not describe any
references on the UFS component. When you look at the composite you
don't see that the client Javascript code in store.html actually
references the Catalog and ShoppingCart services, and proxies to these
services are constructed by hand in the client Javascript code.
I think it would be better if we could write something like follows:
store.composite
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
xmlns:s="http://store";
name="store">
<component name="ufs">
<!-- Point directly to the HTML page -->
<t:implementation.resource location="store.html"/>
<service name="Resource">
<t:binding.http/>
</service>
<!-- Describe references to the target services -->
<reference name="catalog" target="Catalog">
<t:binding.jsonrpc/>
</reference>
<reference name="shoppingCart" target="ShoppingCart">
<t:binding.atom/>
</reference>
</component>
<component name="Catalog">
<implementation.java class="services.CatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<t:binding.jsonrpc/>
</service>
<reference name="currencyConverter"
target="CurrencyConverter"/>
</component>
<component name="ShoppingCart">
<implementation.java class="services.ShoppingCartImpl"/>
<service name="Collection">
<t:binding.atom/>
</service>
</component>
<component name="CurrencyConverter">
<implementation.java class="services.CurrencyConverterImpl"/>
</component>
</composite>
store.html
<html>
<head>
<title>Store</title>
<!-- include a single script, covering multiple bindings -->
<script type="text/javascript" src="sca.js"></script>
<script language="JavaScript">
<!-- Simplified creation of the client proxies -->
catalog = Reference("catalog");
shoppingCart = Reference("shoppingCart");
This introduces the following changes:
In store.composite
- The <implementation.resource> element directly points to store.html,
so when you look at the .composite you know what HTML page is actually
used.
- The ufs component now declares correct references and wiring to other
service components in the assembly.
In store.html
- A single sca.js script is generated for the client to include, very
much like the generated scaDomain.js file, but covering multiple
bindings, and customized for this particular UFS component and the
references that were declared on it.
- The client code is simpler, you can do catalog = Reference("catalog")
or you could do something like catalog = references.catalog (where
references.catalog would be initialized in sca.js), but I think I prefer
the first form as it allows me to pick the name of the variable I'm
going to use and Reference("catalog") also allows execution of some
initialization code when the proxy is initialized.
These changes should be possible with minimum effort but I think they
will improve the sample a lot.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien,
It looks like that, with this approach, we can hide the discontinuity
between the URL on which services are offered and the URL on which the HTML
page that uses them is provided. I like that.
Me too :)
A question from your comments though. Why do you imply that with approach
catalog = Reference("catalog") that no initialization in sca.js is
required? I'm missunderstanding you on this point.
Simon
Sorry that I was not clear, hoping that this will be clearer :) I didn't
mean to say that no initialization would be required in sca.js. The code
in sca.js will probably need to build a map of the references available
in the client and their binding configuration.
I was just trying to say that this pattern would give us the opportunity
to perform (further) initialization on a proxy instance basis.
catalog = Reference("catalog") executes a constructor, returning a new
instance of the proxy, initialized by the code in the constructor function.
catalog1 = Reference("catalog") will create a proxy instance
catalog2 = Reference("catalog") will create a second proxy instance!
This will allow you to work with the proxy state, set conversation IDs,
callback IDs etc. I'm not implying that we should support conversations
or callbacks right away here (even though there's usually callbacks in
Ajax applications) I'm only saying that this pattern puts the proper
structure in place to be able to do it later :)
catalog = references.catalog (or scaDomain.catalog like we currently
have) doesn't have the same capability.
catalog1 = references.catalog makes catalog1 point to a (singleton)
references.catalog proxy
catalog2 = references.catalog makes catalog2 point the same proxy
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
