I am assuming that you could pass session tracking info in the SOAP Header..
The thing I'd like to consider is whether one server could handles all these 200 modular services on one box.. If not, you might want to host them under different AXIS instances on different boxes.. In other words, it might be favorable to host smaller several services instead. Also, if these services are modular and thus not inter-dependent, then keeping them separate gives you the option to move it around independently of the others - such as hosting it to another server cause one particular modular service is used heavily by your users and need to boost it's performance or any other such needs in the future.. -- Rajal -----Original Message----- From: Simon Fell [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 11:18 AM To: [EMAIL PROTECTED] Subject: RE: one big service vs. a set of related modular services I'd advise against tracking sessions via cookies, and instead use a SOAP header, cookie support varies betweens tools and I've found it in general to be an unreliable mechanism. Cheers Simon > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tim K. (Gmane) > Sent: Monday, November 29, 2004 7:03 PM > To: [EMAIL PROTECTED] > Subject: one big service vs. a set of related modular services > > Hi, > > Here's the dilemma that I am facing and I am looking for your > experiences and recommendation. > > I need to expose a lot of methods (over 200 with over 20 > custom types). > The business logic on the server is implemented, very > modular, such as SessionModule, FileModule, UserModule, etc. > > There are other in-process applications that call these API's > directly. > Now, for remoted clients I can do one of 2 things: > > 1) Have one huge interface/web service that lists all these > methods and their implementation calls to the right module. > > 2) Create a set of modular interfaces/web services, one for > each module. > In this case, the client would have to authenticate and start > a session via the SessionModule before it can make use of any > of the other modules (same for #1 above, the client would > have to call the right auth method before it can call any > other methods). > > Authentication will NOT be done at the transport level > (HTTP), but rather by calling a method in the session module > to start a session and stuff it in the HttpSession (if using > cookies to track the session) or something similar (if using > SOAP header for session tracking). > > Session tracking will most likely be done via cookies > (standard HttpSession stuff) because I may need the same > session in a different servlet running in the same webapp, > otherwise I could use SOAP headers. > > I know #1 will work, not hard to implement, but it will be VERY UGLY. > > #2 is more elegant ... > > Is it possible to even implement #2 from a client perspective > (clients will be a Java Axis client and a .NET client)? If I > expose what looks like multiple web services (related to each > other) will I be able to pass the same session cookie from > the Axis client side when I make calls to the various modules > or the session tracking is done for me and it's buried > somewhere deep so that I don't have access to the cookie on > the client side? If I can get access, can you please tell me > how? Custom handlers on the client side? Easier way to get > access to the HttpRequest constructed on the client side and > adding the session cookie to it (and other cookies from the > load balancer, etc.)? > > The question boils down to the session sharing part between > these modules and how I can achieve it, if possible. > > Thanks for your help. > > Tim > > >
