Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 2310 invoked from network); 13 Jun 2008 15:30:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jun 2008 15:30:44 -0000 Received: (qmail 44385 invoked by uid 500); 13 Jun 2008 15:30:42 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 44345 invoked by uid 500); 13 Jun 2008 15:30:42 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 44334 invoked by uid 99); 13 Jun 2008 15:30:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jun 2008 08:30:42 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of samindaa@gmail.com designates 209.85.198.250 as permitted sender) Received: from [209.85.198.250] (HELO rv-out-0708.google.com) (209.85.198.250) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jun 2008 15:29:50 +0000 Received: by rv-out-0708.google.com with SMTP id c5so3744784rvf.28 for ; Fri, 13 Jun 2008 08:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=yL1uHW7Jyv6GM2Ygaaw3ScjPgQqZyOwTjCZZl4dACkc=; b=MDCT/fjacSi+doPHg7w01bT0KTLsyW43xp+R33Dxp1XGIFDkUzMSqbKSIGe7A2ql7P Bcd4LRmMX5wwb/n9BawJO008frOzMoOZx0wB+dYYKU3hmCALUaNTd5w+nWonqA0Hec5H VIjF4ULB/z/udZDTCswAPLvHgO0P6nUXQT2l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=VkQ8FRij++aDRr256KURx/Ye2KhI+8SsiMT9rxKRIAvhlm8IadkL/tg4cMXlI65WuO 04QXSmBYlC9+ru1YoFqBE6xKTL0Qo8TbFNZZIFvUrYOjGqDl6hVQJ/3ZKGpJBn96vow6 Gm9ltSA+zsAxXbJt2txJvxVKAeS/ZFgtXblaQ= Received: by 10.141.68.12 with SMTP id v12mr1925364rvk.111.1213371008405; Fri, 13 Jun 2008 08:30:08 -0700 (PDT) Received: by 10.140.226.18 with HTTP; Fri, 13 Jun 2008 08:30:08 -0700 (PDT) Message-ID: Date: Fri, 13 Jun 2008 21:00:08 +0530 From: "Saminda Abeyruwan" To: axis-dev@ws.apache.org Subject: Re: Extensions to Axis2/Java deployment engine In-Reply-To: <48526AFC.9020104@wso2.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6808_9812291.1213371008398" References: <48526AFC.9020104@wso2.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_6808_9812291.1213371008398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ================================================= 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be able to live in different class spaces. ex: If the bundles needed different hibernate versions they can be easily plug into different class spaces. 2. We will be able to have multiple version of Axis2 instancres running inside same JVM. This require the need of minimizing System properties. 3. Axis2 will be able to initiate same transport with different versions. This will require proper integration of OSGi services. I haven't touched this area yet, otherwise whole situation will be overwhelming. 4. OSGi life-cycle support. This will give the ability to start/stop/install/update/uninstall bundles. ex: I have myModule.jar which would mimic myModule.mar. We will be able use the above actions to to manipulate the AxisModule as we need. 5. Once a user has written a bundle (which mimic aar/mar/transport/etc), they just need to upload them into a "Axis2 bundle repository", where the community can search them and install them into there system, without shutting down the running system. 6. OSGi event framework. When bundle is (aar/mar/transport/etc) install/started/updated/uninstall, using OSGi events other bundles can change there behaviour. 7. When bundle are properly designed, one will be able to deploy these bundles in any OSGi environment. Most of the app servers are in the path of supporting OSGi. All we have to do is to drop our bundles in their repositories and start them 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles. Using HttpService (impl may be native or provided) we will be able to expose them. Equinox has provided some cool bundles, which can be used all OSGi impls such as "servlet-bridge". 8. Once the ConfigurationContext become an OSGi service, any bundle can access it and use it. 9. People will be able to use OSGi registry to register POJOs as OSGi services and make them as web services ( http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html) 10. People would need minimum effort to integrate into OSGi powered Spring etc. ================================================= In Synapse point of view. 1. Mediators can be written as OSGi bundles. When you start the bundle, the proper factory is called and build the relevant object model. 2. Different version of same mediator is highly possible. i.e two mediator can live in two different class spaces. 3. You will be able to remove Sun service providers facility of loading extension to bundles, which will be support in all Java implementations. 4. Synapse guys like embedded devices ? Thank you! Saminda On Fri, Jun 13, 2008 at 6:11 PM, Asankha C. Perera wrote: > Saminda > >> Main aspect of OSGi is version and modularity >> > Can you list the top 5 advantages for Axis2 end users (who develop > services, or develop clients that consume services), and the top 5 > advantages for those who embed Axis2 (such as Apache Synapse etc). I think > this would be very valuable information for me to consider your suggestion, > and assess the impact on Apache Synapse > >> I am really appreciate if Axis2 folks comment on prior. >> > Looking forward to your reply to comment further > > asankha > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-dev-help@ws.apache.org > > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org ------=_Part_6808_9812291.1213371008398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline =================================================

1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be able to live in different class spaces.
   ex: If the bundles needed different hibernate versions they can be easily plug into different class spaces.

2. We will be able to have multiple version of Axis2 instancres running inside same JVM.
   This require the need of minimizing System properties.

3. Axis2 will be able to initiate same transport with different versions.
   This will require proper integration of OSGi services. I haven't touched this area yet, otherwise whole situation will be overwhelming.

4.  OSGi life-cycle support. This will give the ability to start/stop/install/update/uninstall bundles.
    ex: I have myModule.jar which would mimic myModule.mar. We will be able use the above actions to to manipulate the AxisModule as we need.

5.  Once a user has written a bundle (which mimic aar/mar/transport/etc), they just need to upload them into a "Axis2 bundle repository", where the community can search them and install them into there system, without shutting down the running system.

6. OSGi event framework. When bundle is (aar/mar/transport/etc) install/started/updated/uninstall, using OSGi events other bundles can change there behaviour.

7. When bundle are properly designed, one will be able to deploy these bundles in any OSGi environment. Most of the app servers are in the path of supporting OSGi. All we have to do is to drop our bundles in their repositories and start them

8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles. Using HttpService (impl may be native or provided) we will be able to expose them. Equinox has provided some cool bundles,  which can be used all OSGi impls such as "servlet-bridge".

8. Once the ConfigurationContext become an OSGi service, any bundle can access it and  use it.

9. People will be able to use OSGi registry to register POJOs as OSGi services and make them as web services (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)

10. People would need  minimum effort to integrate into OSGi powered Spring etc.
=================================================

In Synapse point of view.

1. Mediators can be written as OSGi bundles. When you start the bundle, the proper factory is called and build the relevant object model.

2. Different version of same mediator is highly possible. i.e two mediator can live in two different class spaces.

3. You will be able to remove Sun service providers facility of loading extension to bundles, which will be support in all Java implementations.

4. Synapse guys like embedded devices ?

Thank you!

Saminda 
   

On Fri, Jun 13, 2008 at 6:11 PM, Asankha C. Perera <asankha@wso2.com> wrote:
Saminda

Main  aspect of  OSGi  is version and modularity
Can you list the top 5 advantages for Axis2 end users (who develop services, or develop clients that consume services), and the top 5 advantages for those who embed Axis2 (such as Apache Synapse etc). I think this would be very valuable information for me to consider your suggestion, and assess the impact on Apache Synapse

I am really appreciate if Axis2 folks comment on prior.
Looking forward to your reply to comment further

asankha


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org




--
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org ------=_Part_6808_9812291.1213371008398--