PageRenderTime 18ms CodeModel.GetById 10ms app.highlight 3ms RepoModel.GetById 1ms app.codeStats 0ms

/razpub/src/razie/assets/package-info.java

http://razpub.googlecode.com/
Java | 96 lines | 1 code | 1 blank | 94 comment | 0 complexity | 661cc432df076da1ab525f4c2adb95f0 MD5 | raw file
 1/**
 2 * Razvan's public code. Copyright 2008 based on Apache (share alike) see LICENSE.txt for details.
 3 *
 4 * Fairly light and flexible asset/resource management framework, a "naked objects" framework.
 5 * 
 6 * <h1>Overview</h1>
 7 * <p>There's a flurry of patterns and styles out there trying to simplify programming. The domain and model-oriented ones make the most sense. There are yet others that deal with the presentation (naked objects) in a similar manner.
 8 * 
 9 * <p>This is my attempt at covering this field, as I strongly believe that this is the way to go and that all applications should be built this way.
10 * 
11 * <h1>Vision</h1>
12 * <p>
13 * There are assets and resources all over the place, like movies, devices, a running windows
14 * computer etc. These can be uniquely identified and managed (remotely).
15 * <p>
16 * The more code supports common asset management, the better they can integrate. This entire
17 * project is mostly about an asset management framework and related utilities for managing those
18 * assets (web servers, soa calls via http or upnp or whatever protocol you'd have).
19 * 
20 * <h2>What about assets?</h2>
21 * 
22 * An asset framework concerns with how they are defined, how we interact with them and not so much
23 * about how they are implemented...
24 * 
25 * <h3>How they're defined</h3>
26 * 
27 * One must define:
28 * <ul>
29 * <li>the asset class (or a proxy class, if the asset is defined in a different environment) - use the
30 * SoaAsset annotation
31 * <li>CRUD+query functionality - overload the AssetMgr
32 * <li>methods/actions that can be invoked - both SoaAsset as well as the AssetMgr
33 * </ul>
34 * 
35 * <h2>Assets and services</h2>
36 * <p>
37 * The service-oriented world is good granularity for providing coarse functionality but it misses
38 * the point when it comes to programming: you now have to think in terms of controller/stupid data,
39 * unless you add a wrapper layer of intelligent objects that delegate their methods to services.
40 * <p>
41 * That's what this entire framework is about: providing a unified set of frameworks to allow rapid
42 * and unified implementation of smart assets which then can be used and controlled remotely
43 * <p>
44 * This is the difference between <code>somerobotservice.move(myrobot, x, y)</code> and
45 * <code>myrobot.move(x,y)</code>.
46 * <p>
47 * An asset-oriented viewpoint is richer than a service-oriented viewpoint since it implies notions
48 * of presentation for the assets, containers of assets and management. It also allows clients to
49 * look natural.
50 * <p>
51 * Why not "object-oriented" but rather "asset-oriented"? The notion of "object" is way too generic
52 * and fuzzy for what we want here. Assets borrow from service the remoteness and add intelligence,
53 * transparent control, and some notional presentation.
54 * <p>
55 * Why not "resource-oriented" but rather "asset-oriented"? I find that the notion of "resource" 
56 * is not exactly what people have in mind when watching a movie...who's the resource? The player 
57 * or the movie? Also, REST does not have a notion of action on resource or sending a message to a 
58 * resource and that's how we all perceive and think about the world...
59 * 
60 * <h2>Inventories or managers</h2>
61 * <p>
62 * I know entity beans are dead (for good reason) but the notion of entity/home is still pervasive 
63 * and makes sense. Factories for objects are abstracted into an <b>inventory</b>, which acts as a locator for
64 * assets. The assets are assumed to be intelligent, but from a generic handling perspective, the
65 * AssetMgr can use inventories to manage assets. This allows you to wrap external classes and
66 * present them as assets. Since the assets are supposed to be used in higher-level scripting, the
67 * end-result is almost the same: "asset.dosomething(a,b,c)" can be translated into
68 * "findInventory().execute ("dosomething", asset, a,b , c)" be the asset management framework.
69 * <p>
70 * The recommendation is, of course, that assets be smart and not rely on inventories except for
71 * location/management/CRUD".
72 * <p>
73 * Another benefit of passing executes through inventories is ease of implementing remote delegation
74 * etc (there's just one place to remote).
75 * 
76 * <h1>Assets</h1>
77 * <p>
78 * Assets are uniquely identified by type, key and location: {@see AssetKey}.
79 * <h1>Frameworks</h1>
80 * <p>
81 * The lightsoa framework provides the service abstraction, which is good for remote block of
82 * functionality. On top of this we add the smart asset objects.
83 * 
84 * <h1>REST</h1>
85 * <p>
86 * Assets lend themselves well to the REST programming. Same as resources, slight semantic
87 * difference. The biggest difference is that one can act on assets, which makes them more suitable
88 * for use by humans :)
89 * 
90 * 
91 * STATE: post-concept, changes but not often
92 * 
93 * @version $Id: package-info.java,v 1.1 2007-10-02 11:54:36 razvanc Exp $
94 */
95package razie.assets;
96