Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)

2011-03-02 Thread Simon Laws 
On Wed, Mar 2, 2011 at 3:54 PM, Yang, Gang CTR US USA
 wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> --- Cut ---
>>
>> Absolutely and we can already create Axis handlers from our policy
>> providers if required. Although these are  of course specific to Axis.
>
> Really? Are you saying that I, as a policy extension developer, can
> write my own Axis2 handlers and tell Tuscany via policy extension
> artifacts to add them to the Axis2 framework in the Axis2 WS binding
> provider? Can you provide a pointer to how this can be done? I guess I
> did not know this when I was prototyping policy extension in 2.0-Beta.

Yep, the policy providers get the opportunity to see binding specific
configuration. You have to know what binding you're dealing with of
course and in the ws/axis case it's an Axis2BaseBindingProvider object
that the policy provider sees. Once you have that you can get at the
Axis ConfigurationContext and you're off to the races. See

http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSServicePolicyProvider.java

We may need to work on that interface a bit but you get the idea,

Other policies need to do other things with the configuration such as
turning on MTOM but without access to the whole context it's difficult
to predict what a policy might need to do.

>
>> >
>> > Another more sophisticated approach, which could potentially hide
> the
>> > underlying framework, could be to map the Tuscany's interceptors to
>> the
>> > underlying binding provider's handlers as I mentioned earlier. On
> the
>> > high level, this could involve the following:
>> >
>> > - A WS binding SPI that would allow Tuscany to inquire about the
>> > underlying provider type so Tuscany knows what type of handlers to
>> > create, say Axis2 or JAX-WS.
>> >
>> > - A WS binding SPI that would allow Tuscany to register a handler
>> with
>> > the underlying provider's framework.
>> >
>> > - When the policy extension definition is processed that requires
>> > insertion of logic into the binding provider's invocation chain,
>> Tuscany
>> > creates a corresponding underlying framework handler, which wraps
> the
>> > extension's interceptor, and registers it with the underlying
>> framework.
>> >
>> > - This underlying framework handler is created such that when called
>> by
>> > the underlying framework, it will call the extension's interceptor
>> > invoke() method with the underlying framework's message context
>> wrapped
>> > in Tuscany's generic message context for the extension's interceptor
>> to
>> > access.
>> >
>> > - Similar extension SPI/API should be provided so that the extension
>> > developer can determine the type of the underlying framework,
>> retrieve
>> > the corresponding message context and process accordingly.
>> >
>> > Hust some thoughts in a hope to help.
>>
>> Glad to have the suggestions Gang! I'm thinking that looking back to
>> our JAXWS base binding.ws may be the motivation for this kind of
>> thing. I wonder whether we, Tuscany, should define yet another SPI for
>> creating interceptors in the guts of the protocol implementation or
>> whether we should rely on some existing and relatively accepted like
>> JAXWS. What concerns we with trying to provide our own abstraction is
>> that inside the handler we're going to have to manipulate the message
>> and the context that surrounds it. Trying to wrap that would be a lot
>> of work. JAXWS has already done that. If you look at the JAXWS
>> extension that Axis provides you can get the JAXWS message context but
>> you can't get the underlying Axis context from the JAXWS context.
>> Hence they are abstracting you away from how Axis physically process
>> the JAXWS message under the convers.
>>
>
> I agree the way I described was not desirable/feasible because Tuscany
> has to be aware of each new provider type and has to add code to do the
> wrapping and abstraction for each individually. To avoid this, we can
> push the wrapping and abstraction to the WS binding provider side since
> the provider knows their implementation as well as Tuscany's SPI. To do
> this, a WS binding SPI, addHandler(Interceptor), can be added take a
> Tuscany Interceptor, wrap it in the provider's native handler and add
> the handler.
>
> The reason I mentioned these approach is to generalize the mechanism for
> all WS binding providers. This is possible because all parties involved
> here has a common base, which is the SOAP. Maybe there's other better
> ways to do this, which can move the abstraction closer toward SOAP.

OK, interesting, this would be a generic alternative to getting in and
manipulating the Axis configuration directly (in the Axis case). I
still come back to thinking isn't this what JAXWS is supposed to do
but maybe I need to give it some more thought.

>
> Gang
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>



-- 
Apache Tuscany committer: tuscany.apache.org
Co-

RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)

2011-03-02 Thread Yang, Gang CTR US USA 
Classification: UNCLASSIFIED
Caveats: NONE

--- Cut ---
> 
> Absolutely and we can already create Axis handlers from our policy
> providers if required. Although these are  of course specific to Axis.

Really? Are you saying that I, as a policy extension developer, can
write my own Axis2 handlers and tell Tuscany via policy extension
artifacts to add them to the Axis2 framework in the Axis2 WS binding
provider? Can you provide a pointer to how this can be done? I guess I
did not know this when I was prototyping policy extension in 2.0-Beta.

> >
> > Another more sophisticated approach, which could potentially hide
the
> > underlying framework, could be to map the Tuscany's interceptors to
> the
> > underlying binding provider's handlers as I mentioned earlier. On
the
> > high level, this could involve the following:
> >
> > - A WS binding SPI that would allow Tuscany to inquire about the
> > underlying provider type so Tuscany knows what type of handlers to
> > create, say Axis2 or JAX-WS.
> >
> > - A WS binding SPI that would allow Tuscany to register a handler
> with
> > the underlying provider's framework.
> >
> > - When the policy extension definition is processed that requires
> > insertion of logic into the binding provider's invocation chain,
> Tuscany
> > creates a corresponding underlying framework handler, which wraps
the
> > extension's interceptor, and registers it with the underlying
> framework.
> >
> > - This underlying framework handler is created such that when called
> by
> > the underlying framework, it will call the extension's interceptor
> > invoke() method with the underlying framework's message context
> wrapped
> > in Tuscany's generic message context for the extension's interceptor
> to
> > access.
> >
> > - Similar extension SPI/API should be provided so that the extension
> > developer can determine the type of the underlying framework,
> retrieve
> > the corresponding message context and process accordingly.
> >
> > Hust some thoughts in a hope to help.
> 
> Glad to have the suggestions Gang! I'm thinking that looking back to
> our JAXWS base binding.ws may be the motivation for this kind of
> thing. I wonder whether we, Tuscany, should define yet another SPI for
> creating interceptors in the guts of the protocol implementation or
> whether we should rely on some existing and relatively accepted like
> JAXWS. What concerns we with trying to provide our own abstraction is
> that inside the handler we're going to have to manipulate the message
> and the context that surrounds it. Trying to wrap that would be a lot
> of work. JAXWS has already done that. If you look at the JAXWS
> extension that Axis provides you can get the JAXWS message context but
> you can't get the underlying Axis context from the JAXWS context.
> Hence they are abstracting you away from how Axis physically process
> the JAXWS message under the convers.
> 

I agree the way I described was not desirable/feasible because Tuscany
has to be aware of each new provider type and has to add code to do the
wrapping and abstraction for each individually. To avoid this, we can
push the wrapping and abstraction to the WS binding provider side since
the provider knows their implementation as well as Tuscany's SPI. To do
this, a WS binding SPI, addHandler(Interceptor), can be added take a
Tuscany Interceptor, wrap it in the provider's native handler and add
the handler.

The reason I mentioned these approach is to generalize the mechanism for
all WS binding providers. This is possible because all parties involved
here has a common base, which is the SOAP. Maybe there's other better
ways to do this, which can move the abstraction closer toward SOAP.

Gang


Classification: UNCLASSIFIED
Caveats: NONE

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

2011-03-02 Thread Simon Laws 
On Tue, Mar 1, 2011 at 4:12 PM, ant elder  wrote:
> On Wed, Feb 16, 2011 at 10:04 AM, Simon Nash  wrote:
>> ant elder wrote:
>>>
>>> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash  wrote:

 ant elder wrote:
>
> On Fri, Feb 11, 2011 at 10:17 AM, ant elder  wrote:
>>
>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash  wrote:
>>>
>>> Actually I would wonder what is the point of using maven to generate
>>> an ant script that does exactly the same as the maven build.
>>>
>>> In 1.x the ant scripts were provided as an alternative to maven that
>>> use local artifacts from the binary distro instead of depending on
>>> remote repositories.
>
> I meant to add, if working offline using local artifacts is
> useful/important then i wonder if that should also be possible with
> the Maven builds in the binary distribution. It might be nice if both
> the Ant and Maven builds could both work offline using the
> distribution artifacts, which would probably mean having the jars in
> the hierarchical directory structure that maven uses and having the
> Tuscany standalone runtimes work with that. At least that would then
> have the jars in a fairly common and understandable structure.
>
>  ...ant
>
>
 From this I presume you mean having these jars under the Tuscany
 installation directory rather than in the user's local maven repo.

 This seems like a good idea as it's first step to creating a more
 embeddable Tuscany runtime installation.

  Simon

>>>
>>> Does anyone know how to do that? It sounds like something someone else
>>> must have wanted to do before, i guess with the assmbly plugin you
>>> must be able to find the local repo and include that in a
>>> distribution?
>>>
>>>   ...ant
>>>
>>>
>> I think the main problem comes when the user wants to use maven to load
>> jars from some place on the file system other than the local maven repo.
>> I spent a bit of time a few months ago looking for a way to do that,
>> but I didn't find one.
>>
>>  Simon
>>
>>
>
> I've now spent a bit of time trying to do this too without much
> success with any automated way. You'd think you should be able to use
> the assembly plugin and copy files from somewhere like
> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
> other ideas ?
>
>   ...ant
>

What was the process you were hoping to follow Ant? It sounds like:

1/ build the Tuscany source to popular .m2/respository
2/ create a distribution which packages .m2/resposityr maintaining the
same structure
3/ install the distribution with the packages respository intact
4/ run mvn but point it at the repository installed from the distribution

is that close?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Tuscany Meetup in London

2011-03-02 Thread Florian Moga 
The meetup is approaching so I've been searching around for a pub near Queen
Elizabeth II Conference Center and I managed to find a single one specifying
wi-fi access [1]... There's also a Starbucks on Victoria St which probably
has wi-fi access. I also found a couple of other places which might have
wifi but I couldn't find that specified, if we like one of the them more we
can give a call and check that out.

[1]
http://maps.google.ro/maps/place?um=1&ie=UTF-8&q=cafe+zest+london&fb=1&gl=ro&hq=cafe+zest&hnear=Westminster,+London,+UK&cid=535865743004748946
 [2]
http://maps.google.com/maps/place?cid=17450563128257755219&q=bars&hl=ro&cd=7&cad=src:ppiwlink&ei=Qg5uTbugFoSosQbo1pD1Dg&sig2=QGlfnzri5J61MmWrxAQalQ&dtab=0

[3]
http://maps.google.com/maps/place?cid=16695285530179229293&q=bars&hl=ro&cd=2&cad=src:ppiwlink&ei=Qg5uTbugFoSosQbo1pD1Dg&sig2=AjeepxE0nKu5KYsu_FMuFg&dtab=0

[4]
http://maps.google.com/maps/place?cid=7201883026239413873&q=bars&hl=ro&cd=2&cad=src:ppiwlink&ei=YQ5uTaXsKtuosQb6_a3PDw&sig2=8EMGupG8r_4PUm7x_wuChQ&dtab=0

[5]
http://maps.google.com/maps/place?cid=1406744021863542483&q=bars&hl=ro&cd=6&cad=src:ppiwlink&ei=YQ5uTaXsKtuosQb6_a3PDw&sig2=z-rug7CN2hE6Jd3Mci_hzQ&dtab=0

[6]
http://maps.google.com/maps/place?cid=193902453723204701&q=bars&hl=ro&cd=4&cad=src:ppiwlink&ei=YQ5uTaXsKtuosQb6_a3PDw&sig2=PvYF_hjc2D7wV93ZiNrP1g&dtab=0

[7]
http://maps.google.com/maps/place?cid=13023163617214978678&q=bars&hl=ro&cd=3&cad=src:ppiwlink&ei=YQ5uTaXsKtuosQb6_a3PDw&sig2=jwCGg-FqnLFVNUdCSTQxpw&dtab=0


On Tue, Feb 15, 2011 at 4:49 PM, Simon Nash  wrote:

> Florian Moga wrote:
>
>> I have just received a response from the QCon team that it is not possible
>> for me to do the Monday evening work at another time so according to what
>> we've been discussing on this thread, I'll be able to get together with you
>> from 11.30 to 12.30. How about a short pub meetup in the proximity of the
>> Queen Elizabeth Conference Center for this time interval and then move to a
>> more adequate place to hack some code (might not even be necessary as
>> there's more to discuss and exchange ideas - samples, website, doc - rather
>> than actually coding)? Sorry for the turn of events...
>>
>>  That sounds fine.  If we can find a pub with free WiFi then we might
> be able to do some work there as well.
>
>  Simon
>
>>
>> On Mon, Feb 14, 2011 at 6:36 PM, Florian Moga > moga@gmail.com>> wrote:
>>
>>Communication with the QCon crew is very slow until now so this will
>>take some time to get a response (e.g. haven't got a response yet if
>>it's ok to change my schedule for Monday). So if we have a confirmed
>>option, I'd go for that at the moment... Of course, I'll let you
>>know if any opportunity shows up.
>>
>>
>>On Mon, Feb 14, 2011 at 3:30 PM, Simon Nash >> wrote:
>>
>>Mike Edwards wrote:
>>
>>On 14/02/2011 10:29, ant elder wrote:
>>
>>
>>Ok it sounds like this is going to happen on the 7th,
>>where shall we
>>do it? If there are no other suggestions I could try to
>>see if there
>>are any rooms available at IBM Southbank.
>>
>>   ...ant
>>
>>Ant,
>>
>>You may well find Southbank difficult at the moment as they
>>are refurbishing all the public meeting rooms - I tried to
>>arrange a meeting there for 21 Feb and could not get anything.
>>
>>
>>Yours,  Mike.
>>
>>
>>Florian was going to ask the QCon organizers whether they could
>>provide
>>a room at the conference venue.
>>
>> Simon
>>
>>
>>
>>
>

Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)

2011-03-02 Thread Simon Laws 
On Tue, Mar 1, 2011 at 4:51 PM, Yang, Gang CTR US USA
 wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> The picture is worth thousands of words. Thanks, Simon. It really helps
> understanding the architecture and thinking process.
>
> I think the basic approach of treating Axis2 or other (JAX-WS, JAX-RPC
> etc.) binding provider module as a building block is a normal practice.
> The issue is that some special capabilities extensions needs to get in
> the middle of that building block. Luckily most, if not all, WS
> frameworks do provide a mechanism to allow access  to their operation
> context and insertion of logic into their invocation chain - Axis,
> Axis2, JAX-WS and JAX-RPC all provide handlers and CXF provides
> interceptor.

Absolutely and we can already create Axis handlers from our policy
providers if required. Although these are  of course specific to Axis.

>
> A simple approach can be to provide a Tuscany API to take an underlying
> provider's handler/interceptor written by the extension developer and
> register it with the underlying framework. But it does not hide the
> underlying provider's implementation from the extension developer.

+1 and I think this is our default position at the moment. Still means
we need to improve the way interceptors are positioned and the way
that we share context but it will basically work now.

>
> Another more sophisticated approach, which could potentially hide the
> underlying framework, could be to map the Tuscany's interceptors to the
> underlying binding provider's handlers as I mentioned earlier. On the
> high level, this could involve the following:
>
> - A WS binding SPI that would allow Tuscany to inquire about the
> underlying provider type so Tuscany knows what type of handlers to
> create, say Axis2 or JAX-WS.
>
> - A WS binding SPI that would allow Tuscany to register a handler with
> the underlying provider's framework.
>
> - When the policy extension definition is processed that requires
> insertion of logic into the binding provider's invocation chain, Tuscany
> creates a corresponding underlying framework handler, which wraps the
> extension's interceptor, and registers it with the underlying framework.
>
> - This underlying framework handler is created such that when called by
> the underlying framework, it will call the extension's interceptor
> invoke() method with the underlying framework's message context wrapped
> in Tuscany's generic message context for the extension's interceptor to
> access.
>
> - Similar extension SPI/API should be provided so that the extension
> developer can determine the type of the underlying framework, retrieve
> the corresponding message context and process accordingly.
>
> Hust some thoughts in a hope to help.

Glad to have the suggestions Gang! I'm thinking that looking back to
our JAXWS base binding.ws may be the motivation for this kind of
thing. I wonder whether we, Tuscany, should define yet another SPI for
creating interceptors in the guts of the protocol implementation or
whether we should rely on some existing and relatively accepted like
JAXWS. What concerns we with trying to provide our own abstraction is
that inside the handler we're going to have to manipulate the message
and the context that surrounds it. Trying to wrap that would be a lot
of work. JAXWS has already done that. If you look at the JAXWS
extension that Axis provides you can get the JAXWS message context but
you can't get the underlying Axis context from the JAXWS context.
Hence they are abstracting you away from how Axis physically process
the JAXWS message under the convers.

>
> Gang
>


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

2011-03-02 Thread Florian Moga 
I understand your concerns related to the documentation we ship. In this
case I'm thinking how a README file should look like? First thing that pops
into my mind is that all READMEs should have a consistent feel and probably
include the same topics like:
  - running the sample
  - short presentation of the technologies involved
  - short presentation of the composite
  - more advanced SCA terminology and concepts explained (which are used in
the sample)

Please add other topics which you feel they need to be part of it.

As an alternative, I was thinking about a problem/solution format but I
don't think we can apply that to all our samples...