> >>> * What's the silliest use of web services you've seen thus far? > > > >> Local invocation of web services. > > > > In general, this tells me that the point of reusability for the service > > is too high. If you have to consume a web service that you don't own, > > then you're doing your best. But if you are providing a web service, you > > should be using service oriented patterns such as session fa�ade and > > service locator. Then the consumer of your web service, if they are > > J2EE, can decide whether or not to hook in at the web services or EJB > > level. If they aren't J2EE, then web services is probably the most > > cost-effective option. It might be, regardless. > > > > Or direct method invocation.
I was assuming local to the machine, not local to the JVM. If it's local to the JVM then it is sillier then I originally thought ;-) My point is that web services should be at the top of the stack. Underneath web services you should have J2EE mechanisms (EJB, JMS, RMI etc.) as needed. At the bottom of the stack, you could provide a method API. However, that method API should be a service-oriented, pass-by-value API so that the innards are consistent regardless of invocation -- else, the API shouldn't be considered part of the stack. As discussed before, you can optimize for the local case, but such optimizations may be dangerous and may be costly. > Do you think that the way it is being sold isn't being or intended to be > interpreted as "if you build it they will come" and excuse from all > architecture? Or do you think that like APIs, SOA will evolve to fit its > users with *some* intimate knowledge on how its *generally* used and how > the > other APIs interact with them? Closer to the latter. I think that SOA defines the principles of distributed computing that have been around for years. CORBA and EJB apps may follow them, just as web services apps may follow them. In the case of web services, following SOA is much more important. But SOA is important to web services because of the limitations of web services. As for how its being sold -- any pitch that says that SOA is new and can only be done with web services is wrong. SOA is not new and its arguable how SOA-compliant web services is. For instance, the concept of a service lease is part of SOA but isn't core to web services. In general, SOA isn't something that can be rigorously examined, like a mathematical proof or a specific software implementation. It is an amorphous and malleable creature similar to OOP. Like OOP, it will be made duplicitous as it is exploited by industry players. This is an inevitable part of a paradigm gaining mindshare, IMHO. Is there value in learning OOP and SOA? Yes, but you should be careful who you are listening to. > Do you mean Big Up Front Design approach? You feel that web services > necessitate this? Web services doesn't necessitate any approach. Methodology is separate from technology. Methodology should be a function of the team and the technical and non-technical challenges a team faces. On large projects, I don't see why multiple methodologies can't be mixed, excepting the technical difficulties of getting two opposing methodologists in the same conversation. In the previous post, I'm suggesting that inter-enterprise development efforts presents challenges that other development efforts don't, just as creating industry standards is different than creating a web-based inventory tool. > If it takes "<int>42</int>" to transfer what I previously would have > transferred as "42", have I still saved a nickel? Or have I merely > shifted > it? This is analogous to the C++ vs. Java debate. On a per operation basis, there are cheaper ways than web services to transfer "42," just like there are cheaper ways than Java to do... well, anything ;-) But this operational cost isn't the cost I was talking about. I was talking about development and lifecycle maintenance costs. Performance is important and can cause projects to fail. But so can going over-budget and creating software that can't be easily repurposed. To address both concerns, I think you have to stack your service interface as discussed before. > Do you feel that web services really simplifies the model? On the low end, yes. On the high end, the nature of XML and HTTP make things clumsy. But those are the 20% use cases for web services. Consider this: web services are about loosely-coupled interoperability. But once your interactions reach a certain level of complexity, isn't the nature of the problem binding the requestors and providers anyway? At this point, maybe you should bite the bullet: go explain to the firewall guy that you have some needs that the firewall just isn't meeting and start shopping for an ORB, MQ-Series or EDI software. So... on the low end, I think that the cost-benefit analysis will favor web services. On the high end, the case isn't as clear. But today's high end is tomorrow's low end... > Do all systems require interoperability? No. > > Do you feel that it will be always true given the advanced amount of > serialization it requires. For instance, if my application takes an E10K > to > run and adding web services makes it take two E10Ks and my realized profit > from this system is 10% of the value of an E10K per year and this is an > internal use application which maybe sends a few messages to our JMS > compatible accounting and ordering systems...how will changing those > interactions to web services benefit me? It won't. (But I don't think I understand the example -- if you are only sending a few messages to other systems, why would web services require twice as much machinery? XML isn't /that/ hard to parse... what are the web services doing to consume all that hardware?) However... if someone else has an E10K and wants to use your system then web services may benefit you -- if they aren't willing to hook in to your non-web services interface. If they are, party on. If you are certain that everyone that comes along will interface with you according to your rules, more power to you. But what happens if someone isn't willing and that relationship is important to the business? It's all about stacking your services interface appropriately so that you are able to offer services across the network. Then it's easy to choose to offer a web service, a J2EE interface or even a direct invocation API if the caller is in the same address space. > At what point should we call web services a "failed to be adopted" > standard > (for CORBA this was bout 10 years) and move on? Declaring that now would make the launch of J2EE 1.4 really awkward... the biggest additions are web services related ;-) But on another note: do we really want to? Also, what do we move on to? I'm assuming that we need software to talk to other software using internet standards in a loosely coupled fashion as cheaply as possible. What's the alternative? > But I thought we were going to write a lot of "Touchstone artifacts" -- > how > do those fit into your agile approach? How does the design of the actual > web services standards compare with agile approaches? How will this > affect > adoption? These are two different discussions. How a project team develops over a few months is completely different from how an industry evolves over years. I don't feel that the two suppositions I offered are contradictory. > To what degree do you think this is why the web succeeded and to what > degree > do you think the fact that it was demand driven which necessitated > interoperability started the cycle? To what degree do you think the web > service committees resemble the OMG's committees? Do you think that these > vendor-driven communities will succeed where the OMG failed? The real action isn't in the committees, it's on the wire and in the project teams. The web took off because you could do a lot quickly for free. I don't think any big vendor(s) could have invented the web in the late '80's for a variety of reasons. When I look at XML-RPC, I see a lot of the characteristics that made the web and XML successful -- e.g., a very simple spec, based on existing standards, implement-able by an advanced undergrad, etc. I'll even say that I don't think that distributed computing could be as simple, as accessible and as interoperable as XML-RPC. If web services was following the timeline of the web, we would just now be seeing things like SOAP emerge. But the heavyweights were much quicker to jump on the web services bandwagon. You have things like SOAP intermediaries that came along very quickly -- faster than things like HTTP cookies and inline images. The SOAP guys improve on XML-RPC by decoupling it from HTTP -- just in case you wake up one morning and decide SMTP is a better transport for your web services. The REST school says SOAP is redundant, violates the basic principles of the web and says that URIs and HTTP GETs can take the place of SOAP -- two different world views in the same space that doesn't have an analogy I can think of in the web history. You have a lot of scary white papers on security for use cases that are improbable for the entire lifecycle of most scenarios. You get BPEL4WS for orchestrating web services into business processes, when there aren't that many web services to orchestrate yet! All of this activity generates a lot of noise. Are all of the great ideas going to take hold? No. Are all of the ideas great? No. Those are easy questions and easy answers. Unless you are in Part 11 terrain, standards are de facto, not de jure. But is it bad that there is all of this activity? I don't think so. For instance, look at the web. It's a great story: it's the little standard that could. But it has pretty serious flaws and limitations. It couples presentation and content. I can't ask "What Sushi restaurants in Raleigh are open at 3:30 p.m. on Sunday" even if every Sushi restaurant in Raleigh has their hours posted on the web. There is no automated way for me to answer that question. I certainly can't count on citysearch to give me the answer, and I definitely don't want to. 13 years later, we're talking about XSLT and the semantic web -- but the HTTP and HTML web has so much inertia now. Are we ever going to be able to unlock data from all the HTML that is out there? Probably not. All that HTML is document data -- semi-structured -- even if the HTML was created from highly structured and easily queried data residing in a SQL DB! Tragic. Wouldn't it be nice if we didn't have to have those conversations? Or at least, we'd started having those conversations earlier -- say 1991? Another easy example is developing user interfaces using the HTTP/HTML model. It's hard. Did it have to be? > > >> Not ignoring object location is different from dwelling on it. For > >> performance you need to think about it. That doesn't mean I should > > have > >> to > >> create needless forked trees of inheritance based on object location. > > > > Hmmm.... Don't know the difference between "not ignoring" and > > "dwelling"... > > > > Some effort is needed to avoid pass-by-value vs. pass-by-reference > > semantics problems. Using value objects helps, though you don't want to > > be passing value objects between two objects that will always be > > co-located. Thus, you need to define what constitutes a service. > > > > That all depends. In the case of EJB there are transactional effects > which > value objects solve as well as serialization effects. If you pass back an > entity reference, there are transaction implications. Also I like to pass > back immutable values often. Good point on transactions. This is a big issue for SOA regardless of implementation. SOA is all about achieving the right granularity, but that's hard to predict. Also, it's completely reasonable to aggregate a service out of other services that can be used standalone. Now you have locality issues as well as transaction demarcation issues and, in the case of EJB, you can address the demarcation issues both declaratively and imperatively. Now, add web services. If your EJB system has a web services interface, then there may also be transactions at a higher level -- your EJB transaction may be bound with other transactions in a 2PC transaction. The other transactions may be on systems that you know nothing about and that wasn't written in J2EE. > I despise EJB local interfaces. In the case of JBoss they are only > relevant where the standards make them relevant. Everywhere else you're > just coding needlessly. That doesn't mean you don't need to take >notice...but having to dwell via object model on the locality or inlocality >is gross IMHO. > > Now would you like to switch sides? ;-) Sure! Sounds like fun... what side do you want me to be on? Cheers! _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
