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. 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 . 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"? 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. -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] > >
