[jbossws-dev] AS7: Re-thinking WS container integration

[Alessio Soldano]

As said on IRC, ad3 is likely to be way to go.
Thanks
Alessio

On 11/25/2010 09:30 AM, Richard Opalka wrote:
> Comments inlined,
>
> Rio
>
> On 11/25/2010 08:37 AM, Jim Ma wrote:
>>>>> I'm just saying that we can see this similarly, we need to think
>>>>> about the deployment process in terms of a) something strictly
>>>>> related to setting up the container for the ws deployment, b)
>>>>> actually creating the endpoint and connecting it to the container.
>>>>> Theoretically speaking (b) is pretty much what is going to the
>>>>> service. This said, for sure we need to deal with the details, but
>>>>> that comes after agreeing on a vision.
>>>> My vision is to support both AS 6 (CR1 or GA)&   AS 7 in JBossWS 4.0.x
>>>> series.
>>>> This is very important to track integration regressions we might
>>>> introduce during the AS 7 integration process.
>>>> And we need to come to an agreement what we'll target with JBossWS 4
>>>> series ASAP ;)
>>> This is one of the key points to discuss. To be honest, I'm wondering
>>> if the pain of supporting both AS 6 and 7 is balanced by any real
>>> benefit here.
>>> Do you think we can really proceed in steps such that each of them
>>> allows to still pass the testsuites (considering the major changes to
>>> spi, the completely different AS structures, classloading, ...)? I can
>>> see major efforts being required for retro-fitting things to AS 6, for
>>> supporting completely different installation steps, etc.
>>> This might even be possible, we need to evaluate pros and cons.
>> IMO, I'd say we should just focus on  AS 7 support in JBossWS 4.x .
>> Given AS7 changed a lot : binary directory structure, MSC , domain
>> model, subsystem  and new DeploymentUnitProcessor, we may need
>> change/refactor a lot of things in SPI , framework and container,
>> deployment script to integrate with AS7.
> I was thinking about it last night and here're pros/cons for both
> approaches:
>
> ad1) Supporting both AS6&  AS7 in JBossWS 4.x series option:
>    * advantages
>      - possibility of SPI&  ASIL cleanup against AS6 while blocked with
> EJB&  WEB issues in AS7
>      - more reliable predictability of our releases
>      - possibility of
>        : core tests&  TCK6 regressions tracking against AS6 during the
> refactoring
>        : CXF (apache) regressions tracking against AS6
>      - back door - if AS 7 will be dropped (IMO this is still possible
> next year - but I don't wish it of course)
>        : we could get benefit of it in the way of cleaned SPI&  AS IL
> integration for AS 6
>        : we won't lost all the development time in this disaster scenario
> * disadvantages
>      - really slow refactoring
>      - big overhead with supporting both AS versions
>      - ugly initial AS 7 integration that will require not trivial effort
> to fix it in the future (like we did AS 5x ASIL cleanup)
>
> ad2) Supporting just AS7 in JBossWS 4.x series option:
>    * advantages
>      - really fast refactoring
>      - better (if not perfect) initial&  later AS 7 integration
>      - no overhead with supporting both AS versions
>    * disadvantages
>      - possibility of big blocking issues (we're hardly depending on EJB
> and WEB - these need to be integrated to AS7 first)
>      - no possibility to track regressions that we can introduce on our own
>      - no possibility to track CXF regressions
>      - no back door (but it wouldn't be our mistake - it was PM decision
> for AS6 ->  AS7 switch)
>
> ad3) Supporting just AS7 in JBossWS 4.x series&  tracking CXF
> regressions in JBossWS 3.4.x series
>    * advantages
>      - really fast refactoring
>      - better (if not perfect) initial&  later AS 7 integration
>      - less overhead with supporting both AS versions (we would have two
> separate branches - one just maintained and one hardly changing)
>      - possibility of CXF (apache) regressions tracking against AS6
>    * disadvantages
>      - possibility of big blocking issues (we're hardly depending on EJB
> and WEB - these need to be integrated to AS7 first)
>      - some time (not significant I think) spent on CXF regressions
> tracking/fixing in JBossWS 3.4.x series
>      - no possibility to track regressions that we can introduce on our
> own in JBossWS 4.x series
>      - no back door (but it wouldn't be our mistake - it was PM decision
> for AS6 ->  AS7 switch)
>
> These are mine ad1) ad2)&  ad3) I came with ;)
> Maybe U can think out other options
> (please write it down if U have some)?
> Maybe U can see other pros/cons for provided options ad1), ad2)&  ad3).
> (please write it down if U have some)?
>
> I think it would be nice to have all the options we'll come with written
> down
> with their pros/cons so we can do final decision.
>
> Let's discuss these&  other alternatives friends.
> We need to decide about supported AS versions and way to proceed ASAP.
>
>> I also agree with you guys all, this is a good opportunity to
>> review/change/refactor in our side(JBWS4.x) to simplify something and
>> make it faster
>> * deploy endpoints faster - review and simplify the old deployers or DAs
>> with new AS7 Deployment api
>> * more manageable - provide interface/api to start/stop endpoints, or
>> transport and monitor incoming message count etc..
>> * rich APIs -  as Alessio talked in the previous email to provide more
>> SPI apis meant for actual user consumption
>> * enhance test suite running - there is embeded as7 for test use ?  and
>> if run one test case we just build one war file not the whole test
>> deployments ...
> Thanks Jim ;)
>> My 2 cents.
>>
>> Cheers,
>> Jim
>> _______________________________________________
>> jbossws-dev mailing list
>> jbossws-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbossws-dev


-- 
Alessio Soldano
Web Service Lead, JBoss