Re: design question
On Friday 17 December 2004 22:53, Andy Kriger wrote:
For example, let's say I have webservice methods implemented by a
class called BusyBee. I want to grab the ID of the MessageContext
Session and use that as a key in my BusyBee.doSomething() method. I
could call MessageContext.getCurrentContext() in the method, but that
breaks the separation of concerns. So I have a method
BusyBee.setSessionId(). How can I call that method and apply the
MessageContext Session info from outside of BusyBee?
It isn't absolutely necessary that your BusyBee class is the one that's
actually exposed as a web service, or is it? Then how about this
public interface BusyBee {
void someMethod();
void setSessionId(long id);
}
public class BusyBeeImpl {
void someMethod() { ... }
void setSessionId(long id) { ... }
}
public class BusyBeeService implements BusyBee {
private final BusyBee _bee = new BusyBeeImpl();
public void someMethod() {
MessageContext ctx = MessageContext.getCurrentContext();
...
_bee.setSessionId(...);
_bee.someMethod();
}
}
In case you're using the Spring framework you could do something like
this
public class BusyBeeService extends ServletEndpointSupport
implements BusyBee {
private BusyBee _bee;
protected void onInit() {
ApplicationContext ac = getWebApplicationContext();
_bee = (BusyBee)ac.getBean(busybee);
}
public void someMethod() {
MessageContext ctx = MessageContext.getCurrentContext();
...
_bee.setSessionId(...);
_bee.someMethod();
}
}
Michael
--
Michael Schuerig They tell you that the darkness
mailto:[EMAIL PROTECTED] Is a blessing in disguise
http://www.schuerig.de/michael/ --Janis Ian, From Me To You
Re: Design question on using Java classes v/s hashes or arrays
- Original Message - From: Rajal Shah [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 15:51 Subject: RE: Design question on using Java classes v/s hashes or arrays I see your point.. If business functionality changes though, then maybe you need to change the method name or something and deprecate the old method.. to solve the issue you bring up. (and work on your SLAs with the clients to make them understand the new behavior or provide both business logic options). I am referring to the versioning of services for extending the functionality of a data object. And having 2 end points can serve the needs to backward compatibility and avoid me to define my objects as hashes. If you use doc/lit messaging rather than rpc/enc, you can add new stuff to a message (But obviously these need to be optional additions, you cannot subtract, and you need to keep semantics 100% consistent. Even so, it does give doc/lit a bit of flexibility. And equally importantly, shows up versioning issues in API signatures fast. I talk about versioning a bit in http://iseran.com/Steve/papers/wstw/ Your document is pretty comprehensive and well thought out! I still have doubts there. There are lots of issues we are let to learn, and only that trial and error will find. I sort of wrote that paper as I was going along, but decided it was time to get stuff out the door. with my current project I wrote the proto server, then did the client (swing based), and soon redid bits of the api for ease of programming and long haul perf. For example one call returned #of items in a queue, another listed the queueID of all elements, and the third took one queueID and returned info about that element. Now what do I do for long haul? Do I boost throughput with a message that lets you specify a list of queue items. Good for http1.0 nagling, saves on net sockets used (good for the server),... But it could make the UI less responsive. Right now I can fill the list in one at a time, with a worker thread to talk to the server. But with a bulk call I dont get an update till the update is complete. I dont see any 'best answer' here. I'll probably add the bulk call for when somebody wants it, but maybe only fetch small chunks, say 4 items at a time, for responsiveness. -steve
RE: Design question on using Java classes v/s hashes or arrays
-Original Message- From: Bill de hÓra [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 12:33 PM To: [EMAIL PROTECTED] Subject: Re: Design question on using Java classes v/s hashes or arrays Garbis, Jason wrote: Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding important information from the WSDL metadata. That is, a user would have to consult some external metadata to understand what is and isn't valid input. This defeats the purpose of using WSDL. I belive a dictionary/data driven approach is a good choice when the interface is unstable or likely to change. Typechecking depends on the nature of the keys used and the argument being passed in. Yup, the issue is more of a design preference (as well as system requirement) as to compile vs. runtime type checking. A related issue is that somewhere we have to define the valid input output structures, as well as the semantics. I lean towards trying to do this fully within the metadata of the system (e.g. WSDL in this case) rather than exernally. This reminds me of my CORBA days, when I would (half-jokingly) demonstrate the only interface you'll ever need: CORBA IDL: Any do-it(in Any); Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class). (This assumes you even want to write this dispatching code...) That would be one approach- it sounds very like a generic method, the most specific version of the.method is selected for the arguments supplied. It's a way to work around the fact that SOAP/WSDL doesn't offer much by the way of polymorphism. It's not btw, a million miles away from using a dictionary. Another option is not to use a custom interface, instead see if the service can be described in terms of HTTP methods, which are stable, polymorphic and highly generic and bind the WSDL to that. This is a real challenge in building tightly-coupled distributed systems with WS It is, but, the point of using WS is to build loosely coupled systems with coarse grained messages. I disagree that this is the point of WS -- this is one major use case, but people are also using WS for fine-grained interfaces (e.g. as the universal Application Adapter mechanism). Granted WS are inefficient and immature, but because it's univerally accepted, this is where the momentum is. (actually, I think that XML is a conspiracy of the hardware manufacturers to boost sales -- hey, let's promote the LEAST efficient data representation possible...) Another take is that tightly coupling systems through fine grained method calls is not a good approach for building web distributed systems the problems Rajal is running into simply reflect that it's an antipattern at best. Not necessarily -- if you're exposing WS to an external client over the Internet, you are correct. If you are using WS internally as a universal connecting technology, fine-grained interfaces and tight-coupling is fine. This is using WS to address the same problems that CORBA did -- except now there is no imposition of any particular technology other than WS. So (e.g.) your VB developers can easily make use of a CORBA server without knowing anything about it. --Jason (As an aside, not using a finegrained approach is no evidence of 'not thinking enough'- far from it) Bill de hÓra -- Propylon www.propylon.com
RE: Design question on using Java classes v/s hashes or arrays
Hi folks, Rajal, you've hit on one of the difficulties of using WS for building a distributed system. WS is not a design center, it's a set of communication protocols. That is, there's no there there. Unlike OO systems (like CORBA, or COM, or even EJB) there's nothing to hang your hat on in terms of solving these kinds of problems. If this was a CORBA system, you could address this in a number of ways -- interface versioning, namespaces (CORBA modules), Naming Service hierarchies, etc. With WS, this is more difficult, since the underlying WS implementation is independent of the interaction protocol and metadata (SOAP/WSDL). Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding important information from the WSDL metadata. That is, a user would have to consult some external metadata to understand what is and isn't valid input. This defeats the purpose of using WSDL. I believe you will need to construct separate endpoints for each version, since as far as WSDL is concerned, these are different entities (the SOAP port and binding information is specific to one message type). Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class). (This assumes you even want to write this dispatching code...) This is a real challenge in building tightly-coupled distributed systems with WS -- it just doesn't provide all the QoS that we're used to in other distributed computing technologies. Another example is session management... good luck Jason -Original Message- From: Rajal Shah [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 5:10 PM To: Axis User Mailing List Subject: Design question on using Java classes v/s hashes or arrays Folks I'm been struggling to find a good design approach to building our web services and wanted to explore options with everyone. Suppose we have a web service which takes in say 3 parameters as input and it returns a list of records of a database with specific column/field information. Now in a future version, I might have to enhance this service to take in 4 parameters as input. Also, in this new version the service would return the list of records with more column/field information then the previous version. What I would like to do, is to publish the service interface now (generating the client stub using WSDL2Java) such that when we come out with the new version of the service - with 4 params and more column info - I still want the apps with the old client stub to still work as is and retrieve the old information from this updated web service. How can we achieve this? Here are some of the thoughts I had: 1. One way to deal with this is to take input parameters as an array or hash and similarly each output record will be a hash/array with the column name and value. I don't like this idea simply cause we're publishing the API and by putting everything as an array/hash makes it look as if we're not thinking enough.. (though this could be a viable option). Plus I don't know, if the XML-Java conversion will work for old client, when there is more information then what was published earlier? 2. Build the signature of the service method with 3 params for now and then provide another service method with 4 params later. This overloading will do the trick for the inputs. (I don't know if SOAP will allow that..) 3. Build a separate endpoint for every version. (yikes) I hope someone can guide me on the right path with regards the design of web services. Thanks. -- Rajal
Re: Design question on using Java classes v/s hashes or arrays
Garbis, Jason wrote: Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding important information from the WSDL metadata. That is, a user would have to consult some external metadata to understand what is and isn't valid input. This defeats the purpose of using WSDL. I belive a dictionary/data driven approach is a good choice when the interface is unstable or likely to change. Typechecking depends on the nature of the keys used and the argument being passed in. Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class). (This assumes you even want to write this dispatching code...) That would be one approach- it sounds very like a generic method, the most specific version of the.method is selected for the arguments supplied. It's a way to work around the fact that SOAP/WSDL doesn't offer much by the way of polymorphism. It's not btw, a million miles away from using a dictionary. Another option is not to use a custom interface, instead see if the service can be described in terms of HTTP methods, which are stable, polymorphic and highly generic and bind the WSDL to that. This is a real challenge in building tightly-coupled distributed systems with WS It is, but, the point of using WS is to build loosely coupled systems with coarse grained messages. Another take is that tightly coupling systems through fine grained method calls is not a good approach for building web distributed systems the problems Rajal is running into simply reflect that it's an antipattern at best. (As an aside, not using a finegrained approach is no evidence of 'not thinking enough'- far from it) Bill de hÓra -- Propylon www.propylon.com
Re: Design question on using Java classes v/s hashes or arrays
- Original Message - From: Rajal Shah [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 10:27 Subject: RE: Design question on using Java classes v/s hashes or arrays Referring to more discussions on the Internet about versioning of web services, this is what I recommend: We need to create a versioning plan for our service that is extensible and one that also guarantees backward compatibility. I've tried out several approaches and that the best practices seem to suggest that we publish a different service for each version as shown in the diagram below. (http://www.webservicesarchitect.com/content/articles/irani04.asp) This choice makes a few decisions: 1. We do not need to worry about the data objects to be extensible or flexible anymore. Instead of using hash tables or arrays we can flat out go ahead and define our data objects as pure Java objects and deal with them solely for this version. Each subsequent version where you have to enhance/extend these objects, you can give them their own definition.. 2. It makes more sense to decouple web services exchange data objects from the actual business data objects. Each web service version can then map their data objects in the business object appropriately and share the baseline functionality that way. 3. The baseline functionality could be a J2EE container and the Web Services layer can act purely as a communication transportation mechanism with it own published classes and data objects. the problem with this is the classic interface versioning problem. While having different endpoints lets you have multiple interfaces with different signatures, you are all sharing a common behviour, the semantics. What if version 1.0 of the interface has one action on, say, deleting an user (like it is immediate), and version 2.0 changes the implementation details so the transaction is queued? Web services have the extra fun of implicit semantics -if a service is colocated in San Jose off fat pipes, and version 2.0 is hosted out of the netherlands instead, callers in the bay area will see a different implicit behaviour (latency, frequency of errors), even if the implementation is identical. I talk about versioning a bit in http://iseran.com/Steve/papers/wstw/ -steve
RE: Design question on using Java classes v/s hashes or arrays
I see your point.. If business functionality changes though, then maybe you need to change the method name or something and deprecate the old method.. to solve the issue you bring up. (and work on your SLAs with the clients to make them understand the new behavior or provide both business logic options). I am referring to the versioning of services for extending the functionality of a data object. And having 2 end points can serve the needs to backward compatibility and avoid me to define my objects as hashes. Your document is pretty comprehensive and well thought out! -- Rajal -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 11:06 AM To: [EMAIL PROTECTED] Subject: Re: Design question on using Java classes v/s hashes or arrays - Original Message - From: Rajal Shah [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 10:27 Subject: RE: Design question on using Java classes v/s hashes or arrays the problem with this is the classic interface versioning problem. While having different endpoints lets you have multiple interfaces with different signatures, you are all sharing a common behviour, the semantics. What if version 1.0 of the interface has one action on, say, deleting an user (like it is immediate), and version 2.0 changes the implementation details so the transaction is queued? Web services have the extra fun of implicit semantics -if a service is colocated in San Jose off fat pipes, and version 2.0 is hosted out of the netherlands instead, callers in the bay area will see a different implicit behaviour (latency, frequency of errors), even if the implementation is identical. I talk about versioning a bit in http://iseran.com/Steve/papers/wstw/ -steve Referring to more discussions on the Internet about versioning of web services, this is what I recommend: We need to create a versioning plan for our service that is extensible and one that also guarantees backward compatibility. I've tried out several approaches and that the best practices seem to suggest that we publish a different service for each version as shown in the diagram below. (http://www.webservicesarchitect.com/content/articles/irani04.asp) This choice makes a few decisions: 1. We do not need to worry about the data objects to be extensible or flexible anymore. Instead of using hash tables or arrays we can flat out go ahead and define our data objects as pure Java objects and deal with them solely for this version. Each subsequent version where you have to enhance/extend these objects, you can give them their own definition.. 2. It makes more sense to decouple web services exchange data objects from the actual business data objects. Each web service version can then map their data objects in the business object appropriately and share the baseline functionality that way. 3. The baseline functionality could be a J2EE container and the Web Services layer can act purely as a communication transportation mechanism with it own published classes and data objects.
