You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Deepal Jayasinghe (JIRA)" <ji...@apache.org> on 2005/09/05 07:26:31 UTC

[jira] Commented: (AXIS2-85) Service Groups

    [ http://issues.apache.org/jira/browse/AXIS2-85?page=comments#action_12322632 ] 

Deepal Jayasinghe commented on AXIS2-85:
----------------------------------------


According the last chat (31st August 2005) following implementation will look like below;

There will be new configuration descriptor called componet.xml , and which can have multiple service elements. 
For each service element available in component.xml there would be ServiceDescription in Axis2, and after deployment happened axis2 does not care form where service came
(from service.xml or component.xml). 
If a component.xml have four service elements then there would be four services in Axis2.

There would be new context called ComponentContext , and it will be director child of ConfigurationContext and latter ServiceContext will be a child of that too.

In addition to that there will be static descriptions and which is called "ServiceGroupDescription" and it will be a direct child of AxisConfiguration and later ServiceDescription will be a child of that too.

My idea is we do not need to introduce new archive file format for the components, and the internal format should be same as service archive. 

> Service Groups
> --------------
>
>          Key: AXIS2-85
>          URL: http://issues.apache.org/jira/browse/AXIS2-85
>      Project: Apache Axis 2.0 (Axis2)
>         Type: New Feature
>     Reporter: Davanum Srinivas
>     Assignee: Deepal Jayasinghe
>     Priority: Minor

>
> Axis2'ers:
> I've been thinking recently about a couple of things with respect to
> Axis2.  First of all, the idea that we might want to support some
> concept of "service groups" - a bunch of individual services which are
> related somehow (via state, implemented with the same code, etc).
> Second of all, I'm thinking of building a JBI implementation on top of
> Axis2, and JBI's notion of "components" are deployable units which can
> each provide multiple services.
> What about changing our model slightly to enable "components" to
> implement more than one Web Service?  This would entail, I believe:
> * Change axis/services to axis/components (just for clarity)
> * Add a "ComponentContext" level to the context stack between
> ServiceContext and ConfigurationContext
> * Components would be "engage()"d just like services (although looking
> at the code I don't see this for services yet... need to dig around
> more)
> * component.xml (replacement for service.xml) would contain 1..N
> <service> elements each of which looks like the current service.xml, so
> the minimal one-service file would be
> <component><service>...</service></component>.  We could allow
> optimizing this to just <service> at the top level too!
> Thoughts?
> Thanks,
> --Glen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira