-Jason ############################################################################ ############################################################################ ######### This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. ############################################################################ ############################################################################ #########
> -----Original Message----- > From: Simon Laws [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 2:21 AM > To: [email protected] > Subject: Re: Handling authentication for non-web services? > > On 10/19/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > > > That's a lot of text to scroll through, so I'll just add my comments at > > the > > top. > > > > In regards to how the service is selected, this is based on information > > within the message. Authentication simply determines if the message is > > allowed to pass on. > > > In regards to the protocol between tomcat and the service, once > > authentication is accepted, the message is simply forwarded to the > > service. > > The service itself handles the entire message parsing. > > > There seem to be some alternatives here then. > > Convert the current services to SCA Components and maintain the servlet > routing component. This would be my first suggestion to get you up and > running and give you a feel for what Tuscany can do. The servlet of course > needs to talk to the services. This can be done either locally or remotely > using a binding of your choice. So the servlet would need to be modified > to > hold references to services in the SCA domain. You can see examples of > Tuscany running in a web app, for example, calculator-webapp. These webapp > samples don't run as part of the distributed domain yet but I'm looking at > that at the moment. > > I don't want to give the impression that I think everything must live > inside > of SCA but just thinking aloud about some other things that could be > done... > > Based on what you have said already I'm assuming that you can't change > your > clients and that they currently provide the XML message as part of an HTTP > POST. > > Construct a gateway component (in place of the servlet) that accepts the > XML > over an HTTP binding. The function of the component would be to route the > message to wired components based on the contents of the XML. To make this > work we'd have to fix up binding.http to accept POSTed data. > On the OSOA page, there is a section on bindings that covers ws and jms, but I have been unable to find documentation on the http, rss, and atom bindings. Is there any documentation that outlines the schema for the various bindings available? > I've seen discussions recently about hosting web applications in SCA as > well > as the other way round. So in the future the solution maybe that you just > take the servlet you have and deploy that as a component. There's no > support > yet though. > > Construct a set of policies to handle the LDAP based authentication > activity > for binding.http . > I've seen the WS policies sample, but I'm still trying to figure the policies system out. If it's not a bother, can you give me a quick example on how I would deal with LDAP based authentication for the http binding given that user name and pw have been passed in the message? > If you can change your clients then there are of bindings that could be > used > while keeping the same XML message structure. > > > The service interface extends our own general MessageService interface > which > > has methods for receiving text messages it will have to parse as well as > a > > more specific service interface for places where services can make > method > > calls directly. > > I don't understand the last bit about "more specific service interface > for > places where services can make method > calls directly". Should it read "...where clients can make method calls > directly"? > In this case, I meant the service interface for a reference given to a service. This isn't that important given that all the service interfaces can be modified at the moment. We're actually moving into phase II of the project where phase I was just prototyping. So it can all be modified at the start of the new phase. > This was more or less an initial attempt at a roll-our-own service > component > > architecture if you will, before I even knew how to goggle those 3 words > > together. I didn't even know SCA existed until last week. HA! I don't > want > > to keep writing code for something that already exists. > > > Glad you found us! > > By TCP, I meant socket, to keep a persistent connection with our > application > > due to some real-time processing requirements, i.e. someone posts some > > information, we want it pushed as quickly as possible out to the > clients. > > As > > > We don't support TCP sockets directly. All of our bindings are currently > at > a higher level but of course ultimately built on TCP. Is it important > that > it is TCP or just that the client is listening waiting for a message? > > far as I can tell, this isn't possible with web clients. (We have both a > web > > front end and a thick client app to the program). > > > It depends how your web client has been written. For example, we have a > level of support for this kind of thing in binding.dwr which allows a fake > reference to be construct from services back to a web client. Under the > covers it is using some HTTP tricks to make it happen. > > The SCA programming model more generally has some concepts that might > help. > The implication of having an open socket between the client and a service > is > that the service holds state about this connection.Typically we try to > think > of services as being stateless but it is often that some state must be > maintained in some circumstances. It might be worth thinking about how to > formalize this relationship with callback and/or a conversational > semantics. Is there a sample on how to handle conversational sematics? I don't quite understand how this works yet. > > > -Jason > > > > > > > -----Original Message----- > > > From: Simon Laws [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, October 18, 2007 12:10 PM > > > To: [email protected] > > > Subject: Re: Handling authentication for non-web services? > > > > > > Hi Jason > > > > > > I expect others in the project who are closer to some of the non web > > > services bindings will have their own views on this. Am setting the > ball > > > rolling by asking some questions. See below. > > > > > > As a general rule I would try and start simple so I wouldn't > necessarily > > > dive into thinking about new bindings, policies etc. in the first > > > instance. > > > Have a go with your front end and an SCA service behind it and then > > expand > > > from there. Even with this you might be facing the binding/databinding > > > question depending on you service interfaces but lets break the > problem > > > down > > > and see what the simple steps are. > > > > > > Regards > > > > > > Simon > > > > > > On 10/18/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > > > > > > > Hello all. I am currently working on transitioning the project I am > > > > working > > > > on from it's current framework to Tuscany. It's already services > > based, > > > so > > > > that is making things easier. Currently, a custom formatted xml > > message > > > is > > > > posted through tomcat. When the servlet recieves it, it does some > > custom > > > > authentication against an LDAP server and then forwards the message > to > > > the > > > > appropriate service for processing. It's very much a roll your own > > > > solution > > > > right now. > > > > > > > > > Is service selection a function of authentication or is this based on > > some > > > information in the message? > > > What's the protocol between the servlet in Tomcat and the service? Is > it > > > the > > > sample XM message? > > > What does the service interface look like, i.e. the service that the > > > servlet > > > forwards to? > > > > > > I would like to better leverage existing technologies and Tuscany > > > > capabilities to improve this process. I need to continue to use the > > > > message > > > > format I'm using. Would I need to write a new binding since it's not > a > > > > format supported by JSON or WS? Or, would I keep doing what Im doing > > > with > > > > my > > > > current services just now registered on a domain and the servlet > > > receiving > > > > the message continue with the custom validation then use the domain > > the > > > > fetch the appropriate service to pass the message along to? > > > > > > > > > A new binding is certainly a possibility. What it sounds like you need > > is > > > a > > > some kind of REST binding to be able to "post" an XML document to a > > > service > > > "post" method. There are a couple of bindings that deal in arbitrary > > data, > > > I.e. binding.http and the feed bindings binding.rss and binding.atom. > > None > > > of these fit the bill directly but they we could potentially tailor > one. > > > > > > Raymond has been doing some work recently on building a demo showing > how > > > XML > > > can be handled (demo/xml-bigbank). This would be worth a look, for > > > example, > > > you can see in the AccountData service how he's dealing with an > > > XMLStreamReader. > > > > > > Venkat has been looking to policy intents to separate the > authentication > > > function from the details of the bindings. You can see an example of > > this > > > in > > > the helloworld-ws-service-secure and helloworld-ws-reference-secure > > > samples. > > > This might be the way to go in terms of associating LDAP based > > > authentication with any bindings you use. That would be a nice > addition > > to > > > Tuscany in it's own right;-) > > > > > > Also, how would I go about writing a TCP/IP window into the app? Just > > > write > > > > my own, or is there some support for this in Tuscany somehow? > > > > > > > > > What do you mean by a TCP/IP window? Socket? Where would that need to > > > provide access to? > > > > > > Pardon my ignorance. I don't quite know all the capabilities and best > > > > practices for dealing with this kind of problem, so I figure it's > > faster > > > > to > > > > ask, even it my questions don't make sense. > > > > > > > > > No problem at all. It's interesting to hear about your scenario. > > > > > > Thanks. > > > > > > > > Jason. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
