Skip to main content
Jump to: navigation, search

Difference between revisions of "Riena/Getting Started with stages"

m (Getting Started with Stages)
 
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Getting Started with Stages ==
+
{{#eclipseproject:rt.riena}}
 +
{{RienaBreadcrumbs|
 +
[[Riena Project]] | [[Riena Getting started|Getting Started]] | Stages}}
  
Developing, integrating, testing, running and maintaining large client/server applications typically involve diverse setups. Stages are Riena´s approach to deal with that. Stages are a concept - not a service or a set classes.
+
== Why Stages? ==
  
All the different setups of servers and clients are almost identical (and that´s what they should). However, there is a small amount of - ermm - stuff (!) that is different. Basically, this mostly boils down to strings that are different e.g. within URLs (e.g. remote service locations) or other data that gets configured with extensions.
+
Developing, integrating, testing, running and maintaining large client/server applications typically involve diverse setups. Stages are Riena´s approach to deal with that. Stages are a concept - not a service or a set of classes.
  
While developing for example a URL for a remote service might look like:
+
All the different setups of servers and clients are almost identical (and that´s what they should). However, there is a small amount of - ''ermm'' - ''stuff'' (!) that is different. Basically, this mostly boils down to strings that are different e.g. within URLs (e.g. remote service locations) or other data that gets configured with extensions.
 +
 
 +
While developing for example URLs for remote services might look like:
 
<pre>
 
<pre>
 
http://localhost:8080/hessian/HelloWorldServiceWS
 
http://localhost:8080/hessian/HelloWorldServiceWS
another is
 
 
http://localhost:8080/hessian/CustomerSearchWS
 
http://localhost:8080/hessian/CustomerSearchWS
 
</pre>
 
</pre>
Line 29: Line 32:
 
That looks cool. Suppose we could just write that once and use it within different environment setups aka '''stages'''.
 
That looks cool. Suppose we could just write that once and use it within different environment setups aka '''stages'''.
  
===== StringVariableManager come to the rescue =====
+
== StringVariableManager come to the rescue ==
Fortunately there is this great StringVariableManager within the bundle 'org.eclipse.core.variables'. One of things it can do is substituting variable expression within strings with their definition, e.g.
+
Fortunately there is this great StringVariableManager within the bundle 'org.eclipse.core.variables'. One of things it can do is substituting variable expressions within strings with their definition, e.g.
 
<pre>
 
<pre>
 
"This is a ${what} bundle."  would become  "This is a great bundle."  with the definition: what := "great"
 
"This is a ${what} bundle."  would become  "This is a great bundle."  with the definition: what := "great"
 
</pre>
 
</pre>
 
The StringVariableManager can be configured programmatically via its API but more useful in our case by extensions, i.e. we can define variables e.g. with such an expression
 
The StringVariableManager can be configured programmatically via its API but more useful in our case by extensions, i.e. we can define variables e.g. with such an expression
<pre>
+
<source lang="xml">
 
<extension point="org.eclipse.core.variables.valueVariables">
 
<extension point="org.eclipse.core.variables.valueVariables">
 
<variable
 
<variable
Line 43: Line 46:
 
initialValue="http://localhost:8080"/>
 
initialValue="http://localhost:8080"/>
 
</extension>
 
</extension>
</pre>
+
</source>
===== Putting it together =====
+
 
 +
== Putting the pieces together ==
 
Riena performs such string substitutions within
 
Riena performs such string substitutions within
 
* all definitions for remote services. See [[Riena_Getting_started_remoteservices | Getting Started with Remote Service ]]
 
* all definitions for remote services. See [[Riena_Getting_started_remoteservices | Getting Started with Remote Service ]]
 
* all extensions that get injected with Riena´s extension injector. See [[Riena_Getting_Started_with_injecting_services_and_extensions | Getting Started with Injecting Services and Extensions ]]
 
* all extensions that get injected with Riena´s extension injector. See [[Riena_Getting_Started_with_injecting_services_and_extensions | Getting Started with Injecting Services and Extensions ]]
  
To be continued!
+
With that we got all for plumbing the pieces together. What is missing is a nice artifact from the Eclipse/OSGi ecosystem to package our stages.
 +
== Stage fragments ==
 +
Why not putting all those stage dependent ''stuff'' into fragments? Fragments are lightweight and a perfect place for data. One stage - one fragment. As mentioned at the beginning there might be various stages (client/development, client/test, client/production, ..). And of course this pattern can also be applied to the server environment setups.
 +
 
 +
Fragments need a host bundle that defines the context for the fragment. Typically there is a bundle that plays the role of a ''main'' bundle, e.g. within Riena´s sample client application it is the "org.eclipse.riena.sample.app.client" bundle. This ''main'' bundle can be used as the host bundle for the stage fragments.<br>
 +
For convenience we store the stage fragments within a special folder in the ''main'' bundle. Within our sample application client you can find a folder called "stagefragments" that contains the stages (currently just one!).
 +
 
 +
Depending on the required stage the appropriate stage fragment needs to be activated, e.g. added to your launch configuration.
 +
== And Finally ==
  
 +
Stages
 +
* are just a concept or a pattern
 +
* extract environment specific ''stuff''
 +
* keep environment specific ''stuff'' in a well known place
 +
* simplify handling with different setups
 +
* are just beautiful
  
 
[[Category:Riena]]
 
[[Category:Riena]]

Latest revision as of 03:49, 8 July 2011

{{#eclipseproject:rt.riena}}

Why Stages?

Developing, integrating, testing, running and maintaining large client/server applications typically involve diverse setups. Stages are Riena´s approach to deal with that. Stages are a concept - not a service or a set of classes.

All the different setups of servers and clients are almost identical (and that´s what they should). However, there is a small amount of - ermm - stuff (!) that is different. Basically, this mostly boils down to strings that are different e.g. within URLs (e.g. remote service locations) or other data that gets configured with extensions.

While developing for example URLs for remote services might look like:

http://localhost:8080/hessian/HelloWorldServiceWS
http://localhost:8080/hessian/CustomerSearchWS

and so on. Within our test environment they become:

http://your.inhouse.server:80/hessian/HelloWorldServiceWS
http://your.inhouse.server:80/hessian/CustomerSearchWS

and finally within production

https://your.prodhouse.server:80/hessian/HelloWorldServiceWS
https://your.prodhouse.server:80/hessian/CustomerSearchWS

As you can see they have a lot in common. We could rewrite them with something like that

${service_host}/hessian/HelloWorldServiceWS
${service_host}/hessian/CustomerSearchWS

That looks cool. Suppose we could just write that once and use it within different environment setups aka stages.

StringVariableManager come to the rescue

Fortunately there is this great StringVariableManager within the bundle 'org.eclipse.core.variables'. One of things it can do is substituting variable expressions within strings with their definition, e.g.

"This is a ${what} bundle."  would become   "This is a great bundle."  with the definition: what := "great"

The StringVariableManager can be configured programmatically via its API but more useful in our case by extensions, i.e. we can define variables e.g. with such an expression

<extension point="org.eclipse.core.variables.valueVariables">
	<variable
		description="Name of the host to connect to"
		name="service_host"
		readOnly="true"
		initialValue="http://localhost:8080"/>
</extension>

Putting the pieces together

Riena performs such string substitutions within

With that we got all for plumbing the pieces together. What is missing is a nice artifact from the Eclipse/OSGi ecosystem to package our stages.

Stage fragments

Why not putting all those stage dependent stuff into fragments? Fragments are lightweight and a perfect place for data. One stage - one fragment. As mentioned at the beginning there might be various stages (client/development, client/test, client/production, ..). And of course this pattern can also be applied to the server environment setups.

Fragments need a host bundle that defines the context for the fragment. Typically there is a bundle that plays the role of a main bundle, e.g. within Riena´s sample client application it is the "org.eclipse.riena.sample.app.client" bundle. This main bundle can be used as the host bundle for the stage fragments.
For convenience we store the stage fragments within a special folder in the main bundle. Within our sample application client you can find a folder called "stagefragments" that contains the stages (currently just one!).

Depending on the required stage the appropriate stage fragment needs to be activated, e.g. added to your launch configuration.

And Finally

Stages

  • are just a concept or a pattern
  • extract environment specific stuff
  • keep environment specific stuff in a well known place
  • simplify handling with different setups
  • are just beautiful

Back to the top