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. 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. 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. 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 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). -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]
