Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Re: Coarse grained interfaces?

Expand Messages
  • Gregg Wonderly
    ... I guess I must be using the wrong words... Having to bridge requires you to compromise in some sense. Continuing to create applications that require
    Message 1 of 42 , Jan 31, 2006
      Eric Newcomer wrote:
      > I think it may be a question of whether or not one
      > believes it's still possible for a single language to
      > become ubiquitous. I don't.
      >
      > Also it's not necessarily a lowest common denominator
      > situation. If you use WS-* for bridging software
      > domains and use Java for what it's best for within its
      > domain, everyone wins.

      I guess I must be using the wrong words...

      Having to bridge requires you to compromise in some sense. Continuing to create
      applications that require bridging is promoting that position and making your
      architecture more susceptible to the speed of technologies related to that
      bridging.

      > I may not have been clear enough in identifying the
      > role I see for Web services. I do not see them as
      > replacing Java - that would be foolish. But as a way
      > to tie together Java, C, COBOL, C++, VB, etc. XML and
      > Web services do a great job.

      Many times WS can do the things (which you are restricted to using) needed to
      solve problems due to the multi language environment. There are times when that
      is desirable. I did say not "always" needed or desirable.

      > One thing I forgot to mention about the STDL
      > experience - we designed STDL data types for
      > compatibility across COBOL, C, and SQL. The
      > intersection of common data types across these
      > languages is pretty small.

      Yes, and that is my point. If you need to do that, do it. But don't turn your
      ESB and entire SOA on end to make that the common mode of operation.

      > Regarding mobile code, I do not think Java has the
      > corner on that market either. It's as possible to
      > create C++ plug ins that are dynamically loaded in a
      > microkernel container, for example.

      Which C compiler generates code that I can run on all processors and is bound to
      all versions of all libraries running everywhere? The other piece is security.
      There is no specification in C for code level security, authentication and
      authorization. We've already seen on the web what can happen when downloaded
      binary code is not controlled by a security system.

      > Unlike Web services, Java was not designed as an
      > interoperability language.

      I think this is where you are missing the whole argument. Java has support for
      interoperability with a wide range of protocols/platforms. If you need to do
      something that Java can't do as your service (I'm not sure what that might be
      given my experience using Java for a wide range of applications), then have at
      it. But, neutralize your homogenenity at the points where it interferes with
      the architecture more than it adds value.

      > It was designed to be a
      > ubiquitous general purpose language. I would never
      > argue that Web services should replace Java, and I
      > can't agree that the reverse is the case, either.

      Humm, Java, like many languages supports web services programming paradigms. It
      is not a replacement for web services. However, mobile code is a replacement
      for and a huge advantage to web services protocols. Java provides one of the
      most robust, flexible and capable mobile code environments in a mainstream
      programming platform that is available today. The security model, URL
      classloader support and the other advanced features of Jini 2.1 are unmatched
      from my perspective.

      As I've said here before, the JERI stack extends the RMI programming model quite
      extensively with a plugable stack. This makes it possible to use RMI calls into
      a wide range of wire protocols. The wire protocol no longer matters when you
      have this capability.

      Web services is like the phone network trying to do ATM. What the phone company
      found out is that routing needs to be alot more dynamic and the application
      needs to be in charge of a lot more and be able to make more choices. The
      inclusion of IP based networking is exactly what allows the wire protocol to not
      be important. What web service do is completely isolate the application from
      network based computing. You get to reimplement all of the facilities of the
      network protocols because you can only send data. This is where web services
      break down.

      Gregg Wonderly
    • Gregg Wonderly
      ... I guess I must be using the wrong words... Having to bridge requires you to compromise in some sense. Continuing to create applications that require
      Message 42 of 42 , Jan 31, 2006
        Eric Newcomer wrote:
        > I think it may be a question of whether or not one
        > believes it's still possible for a single language to
        > become ubiquitous. I don't.
        >
        > Also it's not necessarily a lowest common denominator
        > situation. If you use WS-* for bridging software
        > domains and use Java for what it's best for within its
        > domain, everyone wins.

        I guess I must be using the wrong words...

        Having to bridge requires you to compromise in some sense. Continuing to create
        applications that require bridging is promoting that position and making your
        architecture more susceptible to the speed of technologies related to that
        bridging.

        > I may not have been clear enough in identifying the
        > role I see for Web services. I do not see them as
        > replacing Java - that would be foolish. But as a way
        > to tie together Java, C, COBOL, C++, VB, etc. XML and
        > Web services do a great job.

        Many times WS can do the things (which you are restricted to using) needed to
        solve problems due to the multi language environment. There are times when that
        is desirable. I did say not "always" needed or desirable.

        > One thing I forgot to mention about the STDL
        > experience - we designed STDL data types for
        > compatibility across COBOL, C, and SQL. The
        > intersection of common data types across these
        > languages is pretty small.

        Yes, and that is my point. If you need to do that, do it. But don't turn your
        ESB and entire SOA on end to make that the common mode of operation.

        > Regarding mobile code, I do not think Java has the
        > corner on that market either. It's as possible to
        > create C++ plug ins that are dynamically loaded in a
        > microkernel container, for example.

        Which C compiler generates code that I can run on all processors and is bound to
        all versions of all libraries running everywhere? The other piece is security.
        There is no specification in C for code level security, authentication and
        authorization. We've already seen on the web what can happen when downloaded
        binary code is not controlled by a security system.

        > Unlike Web services, Java was not designed as an
        > interoperability language.

        I think this is where you are missing the whole argument. Java has support for
        interoperability with a wide range of protocols/platforms. If you need to do
        something that Java can't do as your service (I'm not sure what that might be
        given my experience using Java for a wide range of applications), then have at
        it. But, neutralize your homogenenity at the points where it interferes with
        the architecture more than it adds value.

        > It was designed to be a
        > ubiquitous general purpose language. I would never
        > argue that Web services should replace Java, and I
        > can't agree that the reverse is the case, either.

        Humm, Java, like many languages supports web services programming paradigms. It
        is not a replacement for web services. However, mobile code is a replacement
        for and a huge advantage to web services protocols. Java provides one of the
        most robust, flexible and capable mobile code environments in a mainstream
        programming platform that is available today. The security model, URL
        classloader support and the other advanced features of Jini 2.1 are unmatched
        from my perspective.

        As I've said here before, the JERI stack extends the RMI programming model quite
        extensively with a plugable stack. This makes it possible to use RMI calls into
        a wide range of wire protocols. The wire protocol no longer matters when you
        have this capability.

        Web services is like the phone network trying to do ATM. What the phone company
        found out is that routing needs to be alot more dynamic and the application
        needs to be in charge of a lot more and be able to make more choices. The
        inclusion of IP based networking is exactly what allows the wire protocol to not
        be important. What web service do is completely isolate the application from
        network based computing. You get to reimplement all of the facilities of the
        network protocols because you can only send data. This is where web services
        break down.

        Gregg Wonderly
      Your message has been successfully submitted and would be delivered to recipients shortly.