Hi Vikas and all,
 
I implemented a toy according to the architecture I proposed, and I will explain how my toy works,
 
In Synapse core I have servlet called SynapseServlet (I only focused on application server case first) , which extends AxisServlet it only overide doGet() method in order to provide synapse managements. I mean inside doget() method in AxisServlet it handle all the JSP stuffs and for synapse we have to handle them differently and we need different servlet mapping in web.xml too.


So the execution procedure is as follows;

  1. At the deployment time Axis2 deplorer will find synapse module (Synapse.mar) in module directory load it and call it init() method.

  2. Then the synapse module will load synapse.xml and

    1. find rule-engine from that (user can add its own rule engine , just has to implement RuleEngine interface)

    2. Read all the rules in synapse.xml and populate RuleEngine using those

    3. Store RuleEngine as a parameter in AxisConfiguration

  3. I have assumed that there can be only one rule engine in the system , if some one wants to use third party rule engine he can do that inside his RuleEngine implementation

  4. Synapse will be added a dummy service to system with one operation on it and that operations MessageReceiver will be SynapseMessageReceiver

  5. Synapse module has configured to add a Handler to dispatch-phase as its phaseFirst handler

    1. So that one will do dispatch to above mentioned service and Operations

    2. And at the execution time all the other dispatcher will fault through

  6. In invoke method of synapse dispatcher it will first check whether a RuleObject is present if not

    1. It will ask RuleEngine to create a ruleobject for this particular request

    2. It will create RuleObject for that and return that

  7. Dispatcher will add the RuleObject as a property to MsgContext

  8. Next Dispatcher will ask RuleObject to give the corresponding Mediator for the current instance (have a look at RuleObject that I have implemented), and the given Mediator will add to MessageContext as a property

  9. Rule object has to improve the way that will go and add QOS depending on rules

  10. Then Message will go to SynapseMessageReceiver ,

    1. it will get the current Mediator from MsgContext and

    2. call it mediate(msgContx) it will do its job and return boolean true or false

  11. If mediator return false , it will create a new fresh MessageConetxt and copy required properties and parameters etc..

  12. And call engine.receive(msgConetx)

  13. Then the same procedures will follow (when a messge gets to AixiServelt it will call engine.receive())

  14. If the mediator return true, then do what ever you have to do ,


This is my toy all abut , what still to be done

  • Add a synapse deplorer to the system who provide a way to add mediators dynamically

  • RuleObject have to be improved

  • SynapseMR has to be improved


Thanks,
 Deepal
................................................................
~Future is Open~

----- Original Message -----
From: Vikas
Sent: Monday, October 24, 2005 12:04 PM
Subject: Re: Axis2 and Synapse

Hi Deepal/all
 
Are you thinking of something like the stuff in this picture?
 
1) The client sends a request to Synapse.
2) The relevant transport listener picks it up and passes it to the Synapse engine.
3) The engine calls the rule-processor which sends out a list of matching rules or none.
4) The 'Call mediation' part calls the relevant mediations in an orchestrated manner.
5) The control then gets back to the engine.
[Steps 4 and 5 can happen more than once]
6) The engine then calls the actual service.
7) The engine can discard the message at any point due to varied reasons.
 
Let me add a few more points..
* Calling mediations on axis2(and its revisions) would only need changing the part that calls the mediation(these would be similar to client codes calling a service)
* Synapse would be a step above axis2 and might as well go on and support its later versions.
* An externalized rule-processing part.. would allow core synapse-engine to just call it like any other service/mediation.
 
Comments??
 
Thanks!
Vikas.
----- Original Message -----
Sent: Saturday, October 22, 2005 1:22 PM
Subject: Axis2 and Synapse

Hi all;
 

I am bit confusing about current synapse architecture, I want to clarify following some problems

§         If you deploy Axis2 in an application server and if you type localhot:8080/axis2 , you will see axis2 admin  page ,

§         But when it comes to synapse , if some body deploy synapse he should be able to see Synapse admin page NOT axis2 page , to out side word axis2 should not be visible

§         If you deploy axis2.war  in an application server and if you drop synapse.mar (assuming synapse is axis2 module) , then you can not achieve above functionally because , module can not go and change the transport . meaning AxisServlet is the one who handle axis2 web interface , so some one has to change the servlet mapping ,

§         That leads to create a new servlet for synapse (say SynapseServlet) , without doing that you can not achieve those goal.

 

That is mean we need to have separate servlet for Synapse (there can be options) , so if we do that synapse no longer be a just an axis2 module.

 

So my suggestion is to have two main components for synapse,

1.      First part will be the synapse transport , which will hands over messages to AxisEngine when it gets message

2.      Second there should be a separate Synapse module which we do the rule processing and all   

 

This leads to a nice architecture f someone want synapse we will give him a Synapse.war , he can deploy that in an application server. In side that it uses Axis2 functionality, meaning inside Axis2repo/module directory will contain a module called synapse.mar too.  

 

According to this synapse will drive axis2 and synapse.mar will give required configuration to axis2

 

Synapse war file look like below

 

 

here web.xml is synapse web.xml not axis2 one , class folder may contain synapse class

 

 

 


Thanks,
 Deepal
................................................................
~Future is Open~


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to