incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "Synapse/Architecture" by PaulFremantle
Date Wed, 12 Apr 2006 08:41:08 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by PaulFremantle:
http://wiki.apache.org/incubator/Synapse/Architecture

------------------------------------------------------------------------------
  === Configuration scenarios ===
  Synapse is designed to support multiple configuration patterns. 
  
- {{synconfmodels.png}}
+ [http://fremantle.org/synconfmodels.png Picture of Synapse configuration models] 
  
- The simplest patterns are (1) it is embedded inside another system and is configured programmatically
without any XML or config file, and (2) is that it reads its config from an XML file. However,
Synapse is also designed so that it could be embedded in another solution, and might be configured
using JMX, WSDM or any other model.
+ The simplest patterns are 
+  1. Synapse is embedded inside another system and is configured programmatically without
any XML or config file, and 
+  2. Synapse reads its config from an XML file. 
+ 
+ However, Synapse is also designed so that it could be embedded in another solution, and
might be configured using JMX, WSDM or any other model.
  
  === Deployment patterns ===
  
@@ -100, +104 @@

  
  A given instance of Synapse is represented by a SynapseEnvironment (see org.apache.synapse.SynapseEnvironment).
This provides the interface from the mediators into the underlying environment and thus the
separation from – for example – Axis2.
  
- The SynapseEnvironment offers a few simple abstractions: it offers the ability to inject
messages into Synapse or send them onwards (or back in the case of responses), it keeps track
of the classloader (for mediators to load new classes), it abstracts away access to other
resources (such as a registry), and it keeps track of any named mediators (for reuse). 
+ The SynapseEnvironment offers a few simple functions: 
+  * inject messages into Synapse or 
+  * send messages onwards (or back in the case of responses)
+  * get a useful classloader (for mediators to load new classes), 
+  * access to other resources (such as a registry), and 
+  * keeps track of any named mediators (for reuse)
+  * access to global properties (per environment)
  
  The SynapseEnvironment “in-use” for any given message is kept through a pointer in the
message. Thus, if the environment is reloaded or rebuilt (for example if the configuration
is changed), then any messages currently flowing through the system retain their flow through
the existing environment, while other messages could concurrently be flowing through the rebuilt
environment.
+ 
+ The SynapseEnvironment interface looks like this:
+ {{{
+ 
+ public interface SynapseEnvironment {
+ 
+ 	public ClassLoader getClassLoader();
+ 
+ 	public void injectMessage(SynapseMessage smc);
+ 	public void send(SynapseMessage smc);
+ 
+ 	public Mediator lookupMediator(String name);
+ 	public void addMediator(String name, Mediator m);
+ 
+ 	public Mediator getMasterMediator();
+ 	public void setMasterMediator(Mediator p);
+ 
+ 	public Object getProperty(String string);
+ 	public void setProperty(String string, Object object);
+ 
+ 	public void addRegistry(String name, Registry reg);
+ 	public void addRegistry(Registry reg);
+ 	public Registry getRegistry();
+ 	public Registry getRegistry(String name);
+ 	
+ 	public void addMetricsFactory(String URIPrefix, MetricsFactory mf);
+ 	public Metrics getMetrics(String URI);
+ 	public Metrics getMetrics(EndpointReference epr);
+ 
+ }
+ }}} 
  
  === Registry interface ===
  The SynapseEnvironment offers mediators access to configuration and the overall SOA “fabric”
through the concept of one or more abstract “registries”. The registry is abstractly something
that offers access to Strings, Properties, XMLs (including WSDLs, Policies, Schemas), URIs
and EndpointReferences. Each “registry” that Synapse has access to has a name, and in
addition there is a default registry.
  
  The registry is accessed through a “Registry” interface:
  
- <code java>
+ {{{
  public interface SynapseRegistry {
  	OMElement getXML(String uri);
  	String getURI(String uri);
@@ -118, +159 @@

  	List getURIList(String URI);
  	EndpointReference getEPR(String URI);
  }
- </code>
+ }}}
+ 
  A “registry” is accessible from the SynapseEnvironment with:
  getRegistry(String name);
  
@@ -136, +178 @@

  
  Because of the inherent separation of concerns in the Synapse design, Synapse may be implemented
on other systems than Axis2, and so the metrics available from that underlying system are
abstracted through the SynapseEnvironment interface:
  
- ''SynapseMetrics getMetrics(String URI);'' 
+ ''Metrics getMetrics(String URI);'' 
  
  This method returns an object providing the usual metrics (average response time, hit rate,
failure rate, min response time, max response time, etc. Those metrics include metrics for
both the time spent inside the local Synapse environment as well as time spent on onbound
invocation) for any requests made to the given URI.  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message