Benson, Very well put and your strategy sounds spot on.
What I think has become clear is that you are differentiating annotations on your dtos/value objects and on your service methods. That was not clear to me before. I'll agree 100% on the dtos. Let me go into a little more detail on my view on annotations on services so it might help bolster an argument for the availability of an annotationless method of getting a "web service" from a (hopefully) pojo service. (Quotes explained later.) Like you, we have a ton of code that is shared. Many domain/value/dto objects. Many services. And some large number of apps (30+?). Perhaps we are victims of our own success. The "services" (business functionality) are shared by numerous apps. Some web apps, some web services. Different apps and different web services use different parts of some shared services. Bread and butter stuff. Finally, we have a lot of code we wish to expose pretty much as is as web services and we'll be writing *a bunch* of new code that will be used by both a web app (or two or thre..) and exposed as web service. Access control will be handled by our infrastructure and frameworks (somehow accreted onto/into the web services). I put quotes on "web service" above because I guess in the case of a web service being written by us accessed by a client written by us, which is one of our use cases, you would not need soap/wsdl etc. You just need to make "web services" as easily and quickly as possible. So here are some issues: - Different web service exposures of a service. Say you have a java class acting as a service. We already expose such a service with multiple web service apis (XML over http). In app one it has schema one and the schema is dictated to us. In app two it has schema two - we create the schema. In app three its restful. (Right now this is handled in a layer above the service where we write a JibX mapping from Java to xml - or otherwise munge into rest. It's not soap yet, interestingly enough.) If the default way to turn a Java class into a SOAP ws is to annotate the service class, including WebParams to force parameter names, how do you handle the fact you need two different incarnations of the web service? Subclass and annotate twice? Adapter pattern and annotate twice? - Messy apis and annotations = unreadable More of a sylistic issue. We have a few apis that are big in the sense of a few too many arguments to methods and a few too many methods. We could possibly rewrite them but who has time. When you annotate those, including WebParams, it iss essentially unreadable. Only IMHO, of course, but I think it's a real issue. I think this is a fundamental problem with annotations. The code can get messy really fast. - Embedding deployment/access methods into your service So, FooIf.java and FooImpl.java are a service. Say a POJO. In app one, its locally accessed. In app two it's accessed remotely with a custom protocol. In app three its RMI. In app four it needs to be exposed as a web service. If the default way to get Foo to be a web service is to annotate the class, what about those contexts in which it is not a web service? The annotations can be ignored if they are not processed by apt/wsgen/whatever. You'd have to get your build to know when and where not to web service-ize Foo, so I know this can be worked-around, but again, this is a problem with annotations. You are declaring a class to be a web service, which in fact should be context-dependant. Which is part of a bigger problem - annotation are often used to put what *should be* config - external config- into code. Which leads me to: - Depojoization To go with your noting classpath dependancies for snailed classes, what ever happened to the movement to pojos? We are going to Spring for Pojo services, and then we turn around and annotate a class to make it a web service. You import the annotations, you depend on JAX-WS, for example, and that is no longer a pojo. déjà vu EJB all over again. ;-) If I'm way off base, let me know. I've not yet really tried to design the our new framework yet, so the issues might not be as vexing as I was thinking. Brian And on the web services side -->-----Original Message----- -->From: Benson Margulies [mailto:[EMAIL PROTECTED] -->Sent: Tuesday, October 30, 2007 6:02 PM -->To: [email protected] -->Subject: RE: Simple/Aegis model to be supported in the long run? --> -->I think this is a valid discussion on the list, and in fact -->I hope that other users chime in. --> -->My logic goes like this: I/we have a ton of code that is -->shared between the web service and other uses. So long as we -->and our customers are using Java 1.5, we don't want to -->lumber them with classpath noise to support annotations that -->we might add only to allow the classes in the shared code to -->be parts of web service protocols. --> -->Then, we go to actually build a web service that deploys -->some of this code. We don't try to use web services as a -->sort of RMI for some existing class or interface. We design -->them from scratch. That puts us somewhere in the middle of a -->spectrum from Glen's arguments for contract-first on the one -->hand, and deploying any-old-POJO as a service on the other. --> -->I wasn't thinking all that clearly when I wrote my previous -->message. If, indeed, you have POJO's floating around that -->you'd like to remote without encrusting them with -->annotations, then, sure enough, you've got an application -->for Aegis's ability to 'annotate' methods with XML files. -->And that's a reason for us to iron out some issues with some -->of that functionality. --> -->--benson --> --> -->> -----Original Message----- -->> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -->> Sent: Tuesday, October 30, 2007 7:54 PM -->> To: [email protected] -->> Subject: RE: Simple/Aegis model to be supported in the long run? -->> -->> -->> Benson, -->> -->> I'm not sure I understand your last point about unrelated -->to methods. -->Do -->> you want me to take this off the mailing list and tell you at your -->> personal email a bit more about my annotation issues with -->JAX-WS? I'm -->a -->> bit reluctant to clog the list with a this off-topic -->discussion (but I -->> might learn something that mitigates my feelings about -->annotations). -->> -->> Brian -->> -->> -->-----Original Message----- -->> -->From: Benson Margulies [mailto:[EMAIL PROTECTED] -->> -->Sent: Tuesday, October 30, 2007 4:33 PM -->> -->To: [email protected] -->> -->Subject: RE: Simple/Aegis model to be supported in the long run? -->> --> -->> -->Your views of mollusks are about the same as mine. We -->used Aegis to -->> -->avoid classpath dependencies in shared code until very -->recently. At -->> -->which point I sadly decided that I could live with the default, -->> -->unannotated behavior of JAXB at least until I could -->help remove a -->> -->few more bugs from Aegis. -->> --> -->> -->An important distinction: I'm very unperturbed by JAX-WS, since -->> -->those objects are completely specific to the web service, and -->> -->snails don't bother me on them. Aegis' appealed to me as -->> -->de-snailing the ordinary objects that we were shipping -->to and fro. -->> -->Thus, my inclination to spend a lot more time on Aegis -->issues that -->> -->are unrelated to methods. -->> --> -->> -->> -----Original Message----- -->> -->> From: [EMAIL PROTECTED] -->[mailto:[EMAIL PROTECTED] -->> -->> Sent: Tuesday, October 30, 2007 4:35 PM -->> -->> To: [email protected] -->> -->> Subject: RE: Simple/Aegis model to be supported in -->the long run? -->> -->> -->> -->> -->> -->> Not dropping anything sounds good to me. -->> -->> -->> -->> While I've used JAXB and JibX, my buddy over here is -->the one who -->> -->looked -->> -->> at Aegis a while back when we first checked out Xfire and he -->liked -->> -->what -->> -->> he saw. He is on vacation so I can't give you details on -->> -->that one at -->> -->> this time. Well, other than annotations, since you asked, -->> -->which from -->> -->now -->> -->> on I will refer to as snails. -->> -->> -->> -->> There are a some of us who are "not fond" of them. The -->> -->"not fondness", -->> -->> however, is "not occasional." There are a number of -->> -->reasons for that, -->> -->> including the depojoisation (I just made that up) of pojos. -->> -->> -->> -->> What if the objects are used in multiple contexts, like -->> -->ours are? Do -->> -->you -->> -->> annotate it twice? Aegis, with its nice external mapping -->> -->files works. -->> -->We -->> -->> have the same issues with snailing web service endpoints. -->> -->Who says you -->> -->> have only have one WS incarnation of a java service? -->> -->> -->> -->> I have other issues with snailing, too. -->> -->> -->> -->> I'll make a note to get the details on Aegis from my buddy -->> -->whan he is -->> -->> back and get you some more details, if there are any. -->> -->> -->> -->> Brian -->> -->> -->> -->> -->-----Original Message----- -->> -->> -->From: Benson Margulies [mailto:[EMAIL PROTECTED] -->> -->> -->Sent: Tuesday, October 30, 2007 11:45 AM -->> -->> -->To: [email protected] -->> -->> -->Subject: RE: Simple/Aegis model to be supported in the long -->run? -->> -->> --> -->> -->> -->I'm unaware of any plan to drop anything. -->> -->> --> -->> -->> -->Some parts of Aegis, however, get more attention than -->> -->others. The -->> -->> -->parts of Aegis that seem pretty hard to distinguish -->> -->from JAXB, in -->> -->> -->particular. -->> -->> -->Could you comment on why you prefer Aegis to JAXB? Do -->> -->you share my -->> -->> -->occasional dislike of snails in your code (@)? -->> -->> --> -->> -->> -->> -----Original Message----- -->> -->> -->> From: [EMAIL PROTECTED] -->> -->[mailto:[EMAIL PROTECTED] -->> -->> -->> Sent: Tuesday, October 30, 2007 1:01 PM -->> -->> -->> To: [email protected] -->> -->> -->> Subject: RE: Simple/Aegis model to be supported in -->> -->the long run? -->> -->> -->> -->> -->> -->> -->> -->> -->> Glen, -->> -->> -->> -->> -->> -->> First, thanks for the response. -->> -->> -->> -->> -->> -->> But next I can't quite resist pointing out that you -->> -->didn't really -->> -->> -->answer -->> -->> -->> my question ;-) -->> -->> -->> -->> -->> -->> Your points on security are well taken! Our little -->> -->piece of the -->> -->> -->business -->> -->> -->> does not handle HIPAA data, at the moment. (I guess you -->> -->> -->noticed the -->> -->> -->> "Healthcare" part of my sig!) We deal with -->> -->non-patient-specific -->> -->> -->> reference data, although one never knows what -->will come on -->> -->> -->down the -->> -->> -->> line. -->> -->> -->> -->> -->> -->> We do have strict security requirements, however. I had -->> -->> -->typed up much -->> -->> -->of -->> -->> -->> a detailed response explaining our situation, but -->> -->realized this -->> -->is -->> -->> -->> likely not the right forum for that. Perhaps you can -->> -->trust, for -->> -->the -->> -->> -->sake -->> -->> -->> of argument, that I understand the security issues -->> -->> -->involved and that -->> -->> -->we -->> -->> -->> already have extensive security infrastructure that will -->> -->> -->be baked into -->> -->> -->> whatever toolkit we choose (or into which we'll -->bake a new -->> -->> -->toolkit), -->> -->> -->> along with adding support for all the new, fun -->> -->> -->WS-EtcEtcEtc stuff. The -->> -->> -->> same goes for lots of other things one needs for a -->> -->real system: -->> -->> -->logging, -->> -->> -->> monitoring, management, updates, configuration, pizza -->> -->> -->delivery, etc. -->> -->> -->> -->> -->> -->> There are some cases where, indeed, "shoving a bunch of -->> -->> -->unannotated -->> -->> -->> classes to CXF" will be the quickest way to get -->things done -->- -->> -->given -->> -->> -->that -->> -->> -->> the simple model has the extension/integration points we -->> -->> -->need. Which -->> -->> -->is -->> -->> -->> something I still need to check out. But all -->that would be -->> -->> -->moot if the -->> -->> -->> simple model is not long for this world. -->> -->> -->> -->> -->> -->> Does this help? -->> -->> -->> -->> -->> -->> Thanks again! -->> -->> -->> -->> -->> -->> Brian -->> -->> -->> -->> -->> -->> P.S. Oh yeah, and there will definitively be -->> -->situations where the -->> -->> -->simple -->> -->> -->> model is not adequate. -->> -->> -->> -->> -->> -->> -->-----Original Message----- -->> -->> -->> -->From: Glen Mazza [mailto:[EMAIL PROTECTED] -->> -->> -->> -->Sent: Monday, October 29, 2007 7:05 PM -->> -->> -->> -->To: [email protected] -->> -->> -->> -->Subject: Re: Simple/Aegis model to be supported in the -->long -->> -->run? -->> -->> -->> --> -->> -->> -->> -->Brian, are you handling HIPAA data? Then I would -->> -->> -->forget about the -->> -->> -->> -->simple frontend. It's not intended for that. -->> -->> -->> --> -->> -->> -->> -->For good, rigorous coding of Privacy Act/HIPAA data, -->> -->> -->you should be -->> -->> -->> -->starting with WSDL-first development.[1][2] That will -->> -->> -->give you the -->> -->> -->> -->needed experience later when you need to implement -->> -->> -->security. Don't -->> -->> -->> -->want to start with WSDL though? -->> -->> -->> -->OK, then do JAX-WS Java-first with annotations. It -->> -->> -->really isn't -->> -->> -->> -->that much harder than the simple frontend. -->> -->> -->> --> -->> -->> -->> -->Doing either of the above also helps portability--you -->> -->> -->can switch -->> -->> -->> -->much more quickly to Metro (or Axis2, to an extent) if -->> -->> -->you need to -->> -->> -->> -->for whatever reason. -->> -->> -->> --> -->> -->> -->> -->But just shoving a bunch of unannotated classes to CXF -->> -->> -->and hoping -->> -->> -->> -->it will choose the right methods to expose and the -->> -->> -->right ones not -->> -->> -->> -->to does not sound very secure. I don't need to -->> -->tell you that. -->> -->> -->> --> -->> -->> -->> -->Regards, -->> -->> -->> -->Glen -->> -->> -->> --> -->> -->> -->> -->[1] http://www.jroller.com/gmazza/date/20071019 -->> -->> -->> -->[2] http://www.javapassion.com/handsonlabs/wswsdl/ -->> -->> -->> --> -->> -->> -->> --> -->> -->> -->> -->Am Montag, den 29.10.2007, 15:25 -0600 schrieb -->> -->> -->> -->[EMAIL PROTECTED]: -->> -->> -->> -->> Hi, -->> -->> -->> -->> -->> -->> -->> -->> I'm taking a look at web service frameworks. I've -->played -->> -->> -->> -->with Sun's -->> -->> -->> -->> impl of JAX-WS. I've played with (and rejected) -->> -->Axis2. I'm -->> -->> -->> -->about to -->> -->> -->> -->> play with CFX, I've browsed through the -->docs, but had a -->> -->> -->> -->question that -->> -->> -->> -->> I could not find explicitly discussed. Is -->the "simple" -->> -->> -->> -->model here to stay? -->> -->> -->> -->> -->> -->> -->> -->> Perhaps my question is addressed somewhere and I've -->just -->> -->> -->> -->blown past it. -->> -->> -->> -->> Much of the documentation seems to center around the -->> -->> -->> -->JAX-WS front end -->> -->> -->> -->> and relatively little is written about the -->simple front -->> -->> -->> -->end. Perhaps -->> -->> -->> -->> because it is so... simple? ;-) One reason I am -->> -->interested -->> -->> -->> -->in CFX is -->> -->> -->> -->> because of the simple model it supports. We do need -->> -->> -->to support -->> -->> -->> -->> standards, but in some cases we would like to -->> -->turn existing -->> -->> -->> -->> non-trivial code into web services as easily as -->possible. -->> -->> -->> -->Not having -->> -->> -->> -->> to annotate would be a good thing for a couple -->> -->of reasons. -->> -->> -->> -->> -->> -->> -->> -->> If we were interested in CFX in part because of -->> -->the simple -->> -->> -->> -->model, are -->> -->> -->> -->> we "safe" going with CFX? In other words, are the -->simple -->> -->> -->> -->model and the -->> -->> -->> -->> Aegis data binding (which we liked when we -->> -->looked into it) -->> -->> -->> -->going to be -->> -->> -->> -->> around for the long haul, or will CFX evolve -->> -->into a (good) -->> -->> -->> -->JAX-WS impl -->> -->> -->> -->> while dropping support for simple/Aegis? -->> -->> -->> -->> -->> -->> -->> -->> Thanks for consideration of my "newbie" question! -->> -->> -->> -->> -->> -->> -->> -->> Brian -->> -->> -->> -->> -->> -->> -->> -->> Brian D. Horblit -->> -->> -->> -->> Senior Principal Engineer Thomson Healthcare -->> -->> -->> -->> -->> -->> -->> -->> -->> -->> -->> --> -->> -->> -->> --> -->> -->> --> -->> --> -->
