On 9/9/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > > > > partnerLink roles are strictly invoker or invokee. whether you're admin > or > > johndoe, you are still going to interact through a limited set of > operations > > available on the interface (portType), and the partnerLink role tells > you > > which interface it will be, > Hm, sure. My examples was a bit misleading. Better would have been: > UserPortType and AdminPortType. The thing I wanted to point out was > that at least for webapps the capabillities of a service often change > depending on the credentials a user has. Translated to Web Services > this would result in different interfaces/portTypes, so it would make > sense to model it in BPEL as different partnerLinks (adminPL, userPL) > which might be bound to the same EPR.
Yes, those would be different portTypes/partnerLinks/EPRs. > what we need is a way to pass those principles from one invoke to another, > > so the process can be invoked on behalf of some principle (maybe admin, > > maybe johndoe) and invoke another service on behalf of the same > principle. > > or we can bind it statically, so the partnerLink will always invoke on > > behalf of johndoe. > So you want to share the principle across partnerLinks without > explicitly copying auth-data into the EPRs? Thats certainly not that > easy without extending BPEL. I know, and it's something BPEL 2.0 doesn't deal with, and in my opinion would warrant an extension if we want to make it easy to use. Otherwise my proposal would be having a WS-A-extension like that: > > <assign> > <copy> > <from> > <literal> > <sref:service-ref> > <addr:EndpointReference> > <addr:Address>http://example.com/auction/RegistrationService/ > </addr:Address> > <addr:ServiceName>as:RegistrationService</addr:ServiceName> > <basic-auth:user>admin</basic-auth:user> > <basic-auth:password>secret</basic-auth:password> > </addr:EndpointReference> > </sref:service-ref> > </literal> > </from> > <to partnerLink="auctionRegistrationService" /> > </copy> > </assign> > > Perhaps we're talking about the same thing with different words? That would only work if you're using basic authentication all around, care to store clear text passwords, and those passwords never change. Assaf Best, > Tammo >
