I think we've concluded that we agree on many things. Recycle waste,  
Microsoft's protectionism, SI influence etc.

Our difference is that I am assuming that I won't throw away existing  
IT assets and rewrite them in Java and if we can leverage non-Java  
mission critical assets naturally why add the layer of Java? Whereas  
you seem to be making the assumption that rewriting them or wrapping  
them in Java is a most desirable.

Gregg, I agree that if I was writing new code in a business  
environment it would make the most sense to write it in Java. I don't  
disagree. I have said in the past that Java is the COBOL of the new  
millennium. (http://www.ipbabble.com/2005/12/the_jbi_hub_pitfall.html)

LIke it or not J2EE is part of Java as is JMS, JCA, JBI, J2ME etc.  
etc. There is a lot in there it is at least as complicated as CORBA.  
Having built your own proprietary brokers etc. is a luxury - (but  
proprietary ... unless you now have conformed to the specs). Just  
because people aren't using part's of the specs doesn't make Java  
less complicated. Many people didn't migrate from CORBA's BOA to the  
POA but that didn't change the claims that the standard is complicated.

As I said in my blog (http://www.ipbabble.com/2006/01/ 
java_soa_some_lessons_from_cor.html) - and I think we're in agreement  
here. The standards cycle tends to go through a process of eventually  
having to cover every strange use case. This makes the standards  
complicated and causes much of the recycling (once the euphoria of  
watching a cool 'Hello World' demo subsides and people have to add  
enterprise QoS, we tend to repeat the lessons learned in the last  
recycle).

Most people, as you rightly point out, don't need have the stuff that  
(we) so called 'experts' standardize. However we fail to categorize  
parts of the standards for the maturity and enterprise demands of the  
IT organization. We assume people are smart enough to wade through  
the specs and pick the right stuff. They turn to the elusive "best  
practices" for better guidelines. and just when they are about to  
"get it" a new Hello World demo from a new technology come on the  
scene to solve their problem and start the cycle again. But to assume  
that the Java specs are any less complicated than the CORBA or even  
the WS- specs  ..... ?

All I'm saying is this: Way to go Java! When you need to build  
something new and Java fits the need then use it. But let's not  
assume it will work in all cases and let's not force in in places where
it's neither needed or wanted.

Enjoyed/enjoying the debate. I'll give you the last word.

William

On Jan 24, 2006, at 9:36 AM, Gregg Wonderly wrote:

> William Henry wrote:
>> Truly remarkable Gregg. Your zeal is commendable. Your argument is
>> very valuable and worth debating.
>
> I probably have a different, more restricted view of distributed  
> computing than
> many, so your caution may be necessary in running this road with  
> me.  However, I
> still fail to see where WS- technologies have made anything  
> simpler, smaller or
> easier.
>
>> You say: it's all there today. There are many that would say that it
>> was all there with CORBA. Many SOA implementations using CORBA are
>> out there. And that was governed by a very large consortium and not a
>> single vendor. And wasn't limited to one language either. But many of
>> us that deployed CORBA wouldn't and don't force CORBA on people
>> today! It's but one of many useful technologies out there for
>> implementing services.
>>
>> Why CORBA didn't remain the standard used in SOA can be put down to
>> several factors. We've all heard many over there years. I only bring
>> this up because I think it is important o understand from your Java-
>> has-all perspective.
>
> I'm not saying "Java has all". I'm saying Java does distributed  
> computing with
> all the necessary support for that application domain, today.  That  
> is why it is
> a good choice, in my opinion.  It certainly is not optimal for all  
> applications,
> but, to me, that is an API complexity/scaling issue similar to the
> complex/scalable SOA arguments we have here.
>
>> 1) Microsoft wasn't involved - Microsoft being a large participant in
>> the enterprise meant their exclusion from the OMG and CORBA left many
>> doubting whether CORBA could be a complete standard. Having to bridge
>> from COM to CORBA and CORBA to COM seemed unnatural. (products like
>> COMet did this). Microsoft being involved in the WS- community helps
>> in many ways to ease the markets worries that WS- might fail. Mind
>> you it doesn't stop some of the in-fighting ;-) What's interesting
>> from the Java perspective is that Microsoft went the C# route. Hence
>> in this way Java is not unlike CORBA. (Also see notes below about
>> platform control)
>
> Microsoft wants noone else to have and advantage on their OS, besides
> themselves, plain and simple.  They continue to buy up competitors,  
> standardize
> by asimilation and otherwise run over anything that is ahead of  
> them, by
> suggesting a completely different standard.  Everyone buying into  
> it is
> contributing to the slowdown of innovation, plain and simple!
>
>> There are
>> so many political and commercial battles going on that the standards
>> bodies are playing right into ... well right into arguments similar
>> to your own .... like  Java is the cure for cancer and world  
>> peace :-)
>
> I have never uttered such phrases, and I'm sorry that the  
> perception is so
> twisted to drive this kind of commentary.
>
> In other forums I've commented about how much time the software  
> industry
> continues to waste to reimplement the same solutions in new  
> platforms/languages
> for decade after decade.  We've completely failed to address user  
> interface
> issues because we'd rather redesign something in a new language/ 
> platform.
>
> I've been doing software since the early 1980's and have seen a  
> wide range of
> this phenomena.  The VB programmer types and Power Builder Types  
> want to do
> simple applications quickly.  The portability of such applications  
> is almost
> never a consideration.  The ability of these applications to deal  
> with a
> distibuted computing environment is a big issue.
>
> I'm tired of having to port applications from platform to platform and
> reimplement software in different languages everytime I move from  
> machine to
> machine or OS to OS.
>
> Java's cross OS portability and its inherit distributed systems  
> support make
> software development in the network world a lot easier to get right.
>
>> I think
>> this causes paralysis for those implementing SOA. We all need to tell
>> the market to START SMALL!!! (even if you're big). What's interesting
>> about this from your (Java) arguments perspective is that Java has
>> become VERY complicated too.
>
> This, I think is a great indication of what parts of Java people  
> are using.  To
> say that Java has become VERY complicated is a nonsense comment to  
> me.  What
> part of Java has become VERY complication?
>
> Are you a J2EE user? A J2ME user? What about J2SE?  What about J2SE  
> 1.5 language
> features, are those complicating your life?
>
> I have never, ever, written a J2EE application.  I've written  
> Servlets, and use
> them still, but in a small servlet container, Jetty, deployed as a  
> Jini service.
>
> I built my own broker in 1998, before JMS and J2EE existed, and  
> that is the
> foundation of our companies "ESB" that we use for integration and  
> data routing
> between services.  I haven't had to change that container for the  
> past 5-6
> years.  It continues to provide a light weight pubsub container  
> that makes it
> easy to write small object to go inside of it to create customer  
> routing and
> management solutions.
>
> My toolset is different than yours.  That probably causes my view  
> of Java to be
> different from yours :-)
>
>> I think System Integrators (SI) play a big role in popularity of
>> products which then has effect on standards. Where can they make
>> money? Moving to a new standard might mean that they can rebuild what
>> they just built in five years in the "new and improved" technology.
>>
>> I think that analysts need something new and fresh to say to their
>> clients and the market. No use saying "hey what you used last year is
>> just great! Keep using it. We have nothing new to say" And so the
>> analyst feeds into the cycle ... which often becomes recycle. (No
>> offense to Anne et al .. it's just the nature of the business ...
>> they also try to keep vendors honest).
>
> The folks buying into this machinery are what's driving and  
> supporting its
> existence.  If it wasn't profitable, it wouldn't exist.  The  
> vendors continually
> change things and continually out pace your knowledge and that  
> makes you feel,
> if not actually be, dependent on their expertise.
>
>> Quite a cynical view perhaps but that my observation. And it does
>> generate innovation. No doubt about that. But there is a lot of
>> recycle and "emperor's new clothes" factors involved too.
>
> The innovation happens in the small places of the machine, not in  
> the large.
> Supporting the big companies and the standards is useful for many.   
> But, it has
> a pretty huge price from the perspective that you have to  
> continually change to
> keep pace with the vendors.  They are in control, and you're just  
> along for the
> ride.
>
> With Java, I feel I'm in more control.  Sun is a good citizen about  
> trying to
> maintain backward compatibility these days.  They learned their  
> lessons the hard
> ware in the 1.2 and 1.3 days.
>
>> But I reiterate what I said to you earlier: there is no J in SOA.
>> Sure you can wrap everything Java. Bt many of us don't want to, and
>> won't and feel we have very good reasons for not wanting too. Most
>> importantly why force Java in an environment that doesn't need it.
>> Take for instance COBOL application in a CICS environment. Why not
>> just Web service enable them naturally rather than forcing Java and a
>> JVM on front??
>
> I guess your view of what is possible vs mine is different.  Do you  
> know about,
> and undertand the power of mobile code for distributed client user  
> interfaces?
> Do you understand the problem that this solves in an environment  
> where more than
> 2 people are using the software?
>
> Do you understand the importantence and power of application  
> security that is
> beyond "on" and "off" that tunneling based security schemes such as  
> HTTP
> security provides?
>
>> BTW I like Java and have been using it for about 10 years. I just
>> don't see it as the gateway to everything.
>
> It is the gateway to making networked, distributed computing a lot  
> easier, and
> more effective.  Again, the power of Java is realized by taking  
> advantage of
> mobile code.
>
> If you're not able to grasp that possiblities, or don't have time  
> to explore
> them, then you'll probably not see anything in my "raving"  
> responses to some of
> these threads.
>
> In the end, all programming platforms can probably recreate most of  
> the power of
> the Java platform through various mechanism, and can recreate the  
> features for
> combating the 8 fallacies of distributed computing.  But, the  
> languages inbuilt
> security features and its association with mobile code really is  
> the pinnacle
> feature combination from my perspective.
>
> If you don't "get it", my "ravings" will go in one ear and out the  
> other and
> leave with a rather comical view of my posting.
>
> If I can't make you see the issues, then perhaps I can at least  
> give you a laugh
>   for the day :-)
>
> Gregg Wonderly
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to