On 10/20/03 5:47 PM, "Michael D. Thomas" <[EMAIL PROTECTED]> wrote:
> Okay, so that's what I'm trying to do. Now, I'm hoping that you'll
> provide me some feedback to help me accomplish my goals. In the spirit
> of Andy Oliver, I'll try to be as provocative as possible.... If I don't
> incite some disagreement and flames, I've failed.
>
LOL
> * What are you tired of hearing about web services? At this point, web
> services is pretty far along the hype curve. What hype-messages out
> there do you find misleading or tiring? What messages hit the mark?
>
The lie that we're going to just expose some happy service out there and not
ever communicate (stove pipe development as an ideal) and suddenly the two
will just couple... Actually I was tired of this lie with EJB, RMI, CORBA,
DCOM, and DCE...
> * What do you need to know about web services right now? Even better,
> what will you need to know next spring when the book comes out ;-)
>
The dynamic invocation interface and handling document / asynchronous calls.
> * What's the silliest use of web services you've seen thus far? (I have
> a whole chapter devoted to "when not to use web services." I'd love to
> have some more examples. As with all contributions to this thread, I'll
> acknowledge the source as appropriate.)
>
Local invocation of web services.
> * What are your favorite web services resources, books, articles,
> journals, web sites, etc.
>
Not yet published. I want web service information from pragmatists not
evangelists.
> * Service Oriented Architecture (SOA): What do you think about it?
> - SOA is yet another attempt to codify the basic principles of
> distributed computing. As with all previous attempts, SOA will be
> muddied by vendors, ignored by practitioners, and do nothing to improve
> the design and quality of large distributed systems.
> - SOA is cat-skinning method #652.
> - SOA is yet another over-hyped paradigm that is being exploited to
> sell tools, services and training.
> - Why do people keep coming along trying to tell me how to do my job?
>
> - SOA will be the primary distributed computing paradigm by 2006.
> - I've been developing SOA systems since 1943. Stop bothering me.
> - What's SOA?
>
For the most part I like it...it just its another tool in the bag.. Lets
hype it a few years and see if the bosses like it. However, I dislike the
way its preached ("you'll never have to do architecture, human
communication, or forethought again!"
> * Technology integration vs. business integration. I see web services
> being used at a technology level -- "I have these two software packages
> that need to work together, so I use web services to bridge the gap" --
> as well as at a business level -- "BusinessA is setting up a web
> services based electronic interchange with BusinessB." At a plumbing
> level, the challenges are mostly the same, but at a design level they
> are different. For instance, business level integration really needs
> highly visual and declarative artifacts like the ERD for databases to
> enable good planning, negotiating and decision making. In fact, I think
> that a lot can be learned by looking at how databases are designed and
> how the database schema plays a crucial role for both technology and
> business design. Your thoughts?
>
Boooo. Database-based application design sucks.
> * At my most cynical, I proffer that web services is popular because
> most all firewalls have the HTTP and HTTPS ports open. Thus, project
> teams can deploy application code "under the radar" of the enterprise
> security folks and without having to suffer through a full security
> audit. Of course, this means that web services open up the enterprise's
> mission critical systems to profound attack. As with all security
> matters, you really need to design up front rather than bolt security on
> after the application is developed. This is especially important when
> you are orchestrating business processes across many disparate web
> services implementations located across many enterprises. Security and
> authentication issues are fundamental to the success of web services. Do
> you think the current standards and paradigms are up to the challenge?
>
Web services are serialization squared. This sucks for performance. Its
just a wire protocol. The nice thing is that people can totally screw up
their implementation (versus the 1000 page binary spec) and hey...its just
XML, easy to fix/implement/etc.
> * Web services implementations are usually just one face to an
> application. Often, it also has a traditional UI. But both are really
> presentation-level technologies. In my book, I suggest a couple of ways
> to design systems that isolate web services to a presentation layer
> while maximizing reuse between a traditional UI and a web services
> interface. I also cover ways to refactor a pre-web services app so that
> it can cleanly support both a web services and traditional UI front end.
> Thoughts?
Nice.
>
> * Portability and interoperability. Web services is all about
> interoperability. But /porting/ a web services implementation from one
> J2EE server to another can be troublesome. The question of J2EE
> portability can be really tough because, officially, there aren't any
> portability problems between J2EE servers. There are portability issues
> -- what are your experiences?
>
XDoclet.
> * It's one thing to say what a technology is, the problems it solves,
> etc. But let's face it -- all technologists are gamblers. We are
> gambling that the skills/technologies/methodologies/approaches that we
> are developing expertise in now are going to matter in five years. We go
> to monster.com, we type in our keywords, and we hope that we hit a
> jackpot.
>
> When something like web services comes along, I think that it is most
> important to understand the underlying forces that are driving it.
> Technology paradigms often follow the "winner take all" rules of
> scale-free networks or the "law of increasing returns." By understanding
> the underlying forces, you may be able to avoid buying an Edsel, a Beta
> VCR or a NeXT computer. (I once had a professor that bought all three. I
> now consult him on all technology decisions and do the opposite.)
>
Other books have said that web services adoption is top down where the web
was bottom up. This means the heavies (IBM, et al) are pushing this
standard more than the users want it. Thus they're trying to create demand
(now that the app servers are becoming commoditized lets sell tools)... The
web the technology was created, demand preceded its advance and we had
almost universal adoption...if a bit messy.
> Thus, the best discussion we could have is "will (or, what part of) web
> services will matter 5 years from now and why?"
>
I dunno. 5 years ago, I wasn't sure Java would still be around. I question
whether the performance disadvantages of web services will be so pronounced
due to Moore's Law. I do suspect they will continue to fail to live up to
their promises. That�s a pretty easy prediction to make.
> To start that discussion, I'll offer that web services is a simple
> messaging paradigm uses HTTP for transport and XML for semantics. (Note:
> SOAP allows you to choose the underlying transport and other protocols,
> such as SMTP, can be used.) Both technology providers and practitioners
> have coalesced around this model. It's the Reese's cup of our time --
> "you got XML in my HTTP! You got HTTP in my XML!" As with the web
> itself, the simplicity of the model is its greatest advantage. It has
> tons of room to evolve and is evolving in an open manner. If nothing
> else, the lessons we're learning about web services now /will/ matter in
> 2008.
>
This is new? Are you sure it is not a sequel to past technologies with
different acronyms?
> That said, there are a couple of huge hurdles for web services that I
> see.
>
> - There isn't a standard for optimizing XML. Though it isn't really
> true, many will tell you that XML is text. In practice, web services XML
> has to travel the wire in a way that is understandable by both parties,
> which usually means text or encrypted text. This is great when you are
> Amazon or Google and your primary focus is satisfying interoperability
> use cases. However, web services isn't going to beat an equivalent RMI,
> IIOP and/or EJB-based implementation in a foot race. Not even close.
> There is some work being done in standardizing an optimal wire line
> format for XML, but it is a controversial endeavor. Without such a
> standard, attempts to optimize the XML format will result in a higher
> coupling of web services producers and consumers. Such a development
> would be ironic because web services modus operandi is to provide a
> framework for loosely coupled, highly interoperable interactions.
>
Do you think that web services continue to have advantages if they are not
wire-human-readible.
> - Security/authentication. Security and authentication issues make web
> services more complex. For simple point-to-point web services, you can
> overcome a lot of these issues with SSL. But as you get into BPEL4WS
> territory and you are orchestrating web services across many
> enterprises, security and authentication get hard. I like to use UPS as
> an analogy. The UPS truck drives on your property. The driver takes your
> package, confirms your identity, gives it to you, and you sign for it.
> You take delivery on another package, even though it is really meant for
> someone else in your organization and you don't have any business
> opening it. You don't have access to any of the other packages on the
> truck, even though some of the packages may be interesting to you
> because they are bound to customers, suppliers or partners. Just for
> fun, implement that process using web services.
>
I think now we want practical descriptions "do this and this" not more
theory about security on web services.
> - Distributed computing is hard, but web services /seems/ easy. Web
> services, like HTTP/HTML, is really easy for the simple problems. For
> the medium-sized problems, it is still serviceable. But at some point,
> the intrinsic complexities of the problems reveal themselves and you
> need a higher order paradigm to guide you. With HTTP/HTML, that moment
> often comes when a development team goes, "we're not just hacking
> servlets and JSP pages anymore. We're building a content management
> system/inventorying system/e-commerce portal. We should step back and
> think a minute..."
>
Honestly, I can by about 300 books on this viewpoint. Make sure you're
going to present a really new take on it.
> I've seen a lot of examples that show you how easy it is to web services
> enable your code. One of these shows you how to expose the
> add/subtract/multiply/divide functionality of your calculator object.
> Though a great way to demo basic web services plumbing, it really
> represents a distributed computing anti-pattern. It contradicts Jim
> Waldo's (et al) statement from their 1994 paper, "A Note on Distributed
> Computing":
>
> "work in distributed object-oriented systems that is based on a model
> that ignores or denies [the differences between local and remote
> objects] is doomed to failure, and could easily lead to an industry-wide
> rejection of the notion of distributed object-based systems."
>
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.
> Without fully expounding the fine-grained vs. coarse-grained argument,
> let me just say that the lessons of SOA are way more important than the
> lessons of web services. However, poor use of web services is very
> likely to tarnish the acceptance of web services, SOA and general
> distributed computing.
>
Agreed. Web services are useful, but not in nearly half the places they are
marketed as useful. If your manager won't talk to the manager down the
hall, you're doomed to prove Conway's law regardless of what technology
vertical you use.
The Semantic web stuff reads like a bad 60's hippy novel.
-Andy
> Thanks for reading, and I hope that you'll contribute some of your own
> thoughts.
>
> ---------------------------------------------------
> Michael D. Thomas -- Software Developer, Author
>
> "Oracle XSQL" in bookstores now
> "Practical J2EE Web Services" available Spring 2004
>
>
>
> _______________________________________________
> Juglist mailing list
> [EMAIL PROTECTED]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership. In fact they probably most definitively disagree with
everything espoused in the above email.
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org
