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

Re: [service-orientated-architecture] SOA and mobile code

Expand Messages
  • David Forslund
    ... The smaller number of methods I don t think help very much. To understand the semantics of the data being transported, one must invoke some other
    Message 1 of 95 , Jun 30, 2003


      Sergey Beryozkin wrote:
      David Forslund wrote :
       
      >Generic api such as post and get do nothing to help in interoperability.
      What they do is they can help to mimimize a cost of change. A client can always rely on the fact that it can *post* some data to or *get* some data from a service. How that service processes/produces these data is not a client's problem at all. And as such, they interoperate by relying on an interface with just 2-4 methods.
      The smaller number of methods I don't think help very much.    To understand the semantics of the data being transported, one must invoke some other convention, which just moves the problem around.   That may or may not make it easier to deploy an application.   If I send data from my server to the client that the client has no idea what it is, they are unable to process it.  I need to be able to describe the data in some way with some level of semantics.  You may not like the signature of a method ( a behavior) to define the semantics, but you do need some convention for the data transport.
       
      >Dynamic discoverable apis are not hard to manage and are common place in CORBA >and other systems.  Generic methods are disireable but can actually help in them >management of dynamic data types. 
      I'm not sure : are you referring to something which is "reflection" ? If so, then such reflective data are different from application/business data one would pass with *post*, for example. Those data have no information at all about methods which need to be invoked (with SOAP RPC they actually do, in which case POST is just used for tunneling, and as such, cost of change grows, which applies to reflective data as well).
      I don't follow your discussion.  Simple method signatures will lead to more complex data to resolve the semantics.   I don't see the simplification.
      The full API of a server in CORBA can be discovered and fully implemented dynamically.  This includes full type checking.

      Dave
       
      Cheers
      Sergey Beryozkin
      ----- Original Message -----
      Sent: Monday, June 30, 2003 12:18 PM
      Subject: Re: [service-orientated-architecture] SOA and mobile code



      Sergey Beryozkin wrote:
      Hello,
      I think you're discussing several issues here, apologies if I'm wrong.
      1. Interoperability
         Surely, one can try to achieve it with CORBA deployed everywhere. However, most probably, you'll never be able to achieve it for the reasons like politics, etc. It's unrealistic to expect all parties involved will use Corba/Dcom, etc on both ends
         So,  we can move to Web Services now, where all parties agree, but...
      I agree, but I think it is said that people put a closed proprietary mechanism in the same category as an open, international standard.   This has been a steady drumbeat that disguises the underlying issue.  
      2. How do we interoperate with Web Services ? One way is to apply an OO paradigm (ala SOAP RPC - this is only part of OO paradigm, OGSA Grid supports it completely, but they don't use SOAP RPC). IMHO, there's some value in it when one still works in a fairly confined environment, when a fast proof of concept is required, etc. However, in a much more distributed decentrilized environment, which WEB is, the cost of change to an RPC-like interface can increase significantly, simply because if you change one method in your interface, potentially a very big number of systems will need their proxies get regenerated, etc.
      That's why, the bigger the scale, the more value one can see in using *generic* methods, like get and post [1], as well in passing pure data rather than tunneling method frames, this is my interpretation of Sean's opinion. One still needs to agree (in many cases) on a data format, but what is important here, is that changes to that data format over time does not necessarily mean one will have to change an underlying Corba application that processes that data.
      Generic api such as post and get do nothing to help in interoperability.  Generic methods involving dynamic data types are important but quite orthogonal to restricting to a simple post and get method.  Dynamic discoverable apis are not hard to manage and are common place in CORBA and other systems.  Generic methods are disireable but can actually help in them management of dynamic data types.  This is how we have designed a number of standard services.   This is quite independent of whether one uses CORBA or WebServices or Jini, or whatever.

      Dave
      Cheers
      Sergey Beryozkin
       
       
       
      ----- Original Message -----
      Sent: Sunday, June 29, 2003 5:12 AM
      Subject: Re: [service-orientated-architecture] SOA and mobile code

      A service is expressible in a OO way but can be implemented with or without OO.  If you define
      methods through an interface you have defined it within an OO paradigm.  

      CORBA does not equal OO, and vice versa.  CORBA enables OO with difficulty because
      it fully supports non-OO languages. A purer example is now available as something called ICE from the
      ZeroC folks (http://www.zeroc.com).  

      As to why CORBA hasn't been deployed everywhere, the answer is rather simple. First, it has been
      deployed essentially everywhere within industries.  It has been the only choice for more than a decade.  
      The reason it hasn't been embraced in some circles has to do with industrial politics.  When MS lost
      the IIOP protocol battle in the middle 90's, they have done about everything they can to block the
      advance of CORBA, because it represents a non-proprietary solution to distributed computing and this
      was not a part of their business model.   CORBA isn't necessarily that great, but it solves the problem
      it set out to do very well.  It works, and interoperability is common place.  It will take quite a while
      before WebServices reaches this level of interoperability.   When WebServices is used to solve the same
      problems CORBA was used for, it will be just as complex.   We need to find ways of reducing
      complexity wherever we can.   Abstracting services above the transport layer is one of those ways.   UML
      is the lingua franca for doing this and it provides full support for OO.   Not using it is like saying I don't need
      half of a language I've learned.   Use OO where it is useful, don't use it where it is not.  That is the lesson
      we've learned using OO in distributed computing for the past decade.   Reusable, interoperable components
      work and have value.

      Dave

      Sean McGrath wrote:
      At 08:14 28/06/2003 -0600, David Forslund wrote:
        
      I understand completely the simplicit of "puts" and "gets", but this
      basically argues that there
      is no value in the management of complexity with OO methodology.
          
      I believe there is value in it, but only within spheres of influence. In 
      SOA speak, I believe
      the right place to leverage OO's complexity management facilities is behind 
      the service
      boundary - not exposed across service boundaries.
      
      If OO is as good as you say we need to ask ourselves why the world has not 
      moved on to more
      interesting problems having deployed CORBA everywhere.
      
      regards,
      Sean
      
      
      
      ------------------------ Yahoo! Groups Sponsor ---------------------~-->
      Looking for the latest Free IT White Papers?
      Visit SearchSecurity.com to access over 500 white papers.
      Get instant access at SearchSecurity.com Today
      http://us.click.yahoo.com/ayjvfD/QLNGAA/uitMAA/NhFolB/TM
      ---------------------------------------------------------------------~->
      
      To unsubscribe from this group, send an email to:
      service-orientated-architecture-unsubscribe@yahoogroups.com
      
       
      
      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
      
      
        



      To unsubscribe from this group, send an email to:
      service-orientated-architecture-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


      To unsubscribe from this group, send an email to:
      service-orientated-architecture-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



      To unsubscribe from this group, send an email to:
      service-orientated-architecture-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    • David Forslund
      ... Our goal from the beginning is to use a World-Wide WAN. CORBA does this just fine as do other technologies. It is not just for decentralizing processing
      Message 95 of 95 , Jul 8, 2003


        Kaleem Aziz wrote:
        Really enjoyed your debates! As to the disagreement part of it, I
        believe that while SOA applies to CORBA because it decentralizes the
        processing on a computer, SOA as envisioned in case of Web Services
        is World-wide WAN (of course, non-VPN).
        Our goal from the beginning is to use a World-Wide WAN.  CORBA does this just fine as do other technologies.  It is not just for decentralizing processing on a computer.   The reason we chose CORBA 10 years ago was because it is an international non-proprietary standard that works.   We have found that it works on a world-wide scale without any troubles.      We strongly recommend
        using XML as a vital part of this process.  I believe that CORBA may not work on a world wide scale today, not for technical reasons
        but for political reasons.  It seems to be regarded as a non-Internet, proprietary solution.   Perhaps also it is seen as too
        complex.   Unfortunately distributed computing on the Internet is inherently a complex process.  As web services become
        more complete, they are inheriting the complexity of CORBA, with just a different face on it.   I believe SOA is a higher
        level view of what is needed on the Internet (as encompassed in our article cited below), and should have a broader
        applicability than any given technology for distributed computing.
        
        Dave, I believe that when you are faced with the problem of expanding
        your CORBA implementation world wide (with the practical problems of
        how much money can be spent, how fast the whole transformation can be
        done, the business edge it will win for your corp vs not, etc.), you
        will find Web Services more practical than CORBA. It is like you can
        build an airplane using only a screw driver, or you could first work
        on a tool that eventually will help in creating an airplane. I see
        CORBA as a valuable tool in the toolbox, and XML as a highly
        automated multi-dexterous tool that will eventually help us create a
        larger World-wide WAN. 
        
        Carrying forward the toolbox analogy, as a carpenter, one could argue
        whether he'd want to fix a garage door or a two way door for the
        entrance; but no matter how stronger he thinks his version of the
        door is for the houses world wide, it is the home owner (well, his
        wife in most cases :-)) that would decide which one goes well for the
        house in question.
        
        As written in a report, web services is all about standards -- giving
        you the same benefit of what standard electricity sockets and plugs
        gave to the electrical appliances. 
        I agree!   The problem is that today web services is much less mature and incomplete than the existing
        CORBA standards, and seems not very interested in leveraging the CORBA standards.  Today, I can
        develop my code with one vendor's product and then run it on another vendor's product without
        even recompilation.   Currently there is no standard API for web services.   There are numerous
        proprietary ones.   Today, there are domain-specific interface specifications in CORBA, but no
        comparable ones in web services.   Probably the ebXML specs are the closest but they deal with
        broader issues.   As we move to web services, these issues need to be resolved.   Today, I can run
        with a very mature robust world-wide infrastructure using CORBA.   It is zero-cost (all open source)
        and completely non-proprietary.  
        
        Coming to REST, REST or SOAP is a separate debate altogether. Just
        like CORBA and Web Services can exist in their different domains,
        REST and SOAP are not mutually exclusive in being able to thrive
        either. Having said that, REST's architecture is attractive to low
        cost Web Services and the future towards semantic web.
        Understandably, doing SOAP based Web Services will take longer and
        will be less pervasive to create a semantic web or to poliferate Web
        Services far enough (outside of the developed/capitalist countries).
        While most do not like or understand how REST can stand without
        complex and efficient messaging, I really like that the best example
        of such a system is available as the internet today.
        I agree wholeheartedly.  The web today is an excellent world-wide document management system, not
        a world-wide distributed computing infrastructure.   People are trying to move it to that and making
        good progress.  Whether that should be REST or not is certainly open for debate, as we have seen.
        
        Within Web Services, in my view, there are at least two sects (heh
        heh, but as a positive I didn't say cults :-)). One who work for
        large enterprise integrations, who evidently don't appreciate REST
        because it doesn't add value to their project the way SOAP does; and
        the second who work for semantic web who "REST: let SOAP rest". While
        each percieve both as different ways to the same problem, I see them
        as two different tools with different applicability. Which one you
        would use is a value judgement as an architect, as much as the kind
        of bolt a carpenter would use for different doors and windows.
        
        One last point about something that you two discussed: how much do
        you want to expose on public domain. Would you want to expose your
        database as a web service? I would say no, but there have been
        examples of people doing just that. It is a judgement call of how
        much information you'd keep private vs how much you'd outsource --
        just as much as whether you'd have your computer as a bare
        motherboard (the key working parts), or cover it in a chassis and
        then call it a computer. Bad applications of every technology have
        always been done and people have always have difficulty moving on by
        learning new stuff and unlearning old stuff, probably that's because
        that's how we learn?
        I agree!   I think it is good to have an infrastructure that allows for differing levels of exposure of
        information.  Unfortunately, people have seen fit to expose their database on the internet directly
        through a web interface.   That this is easy to do today is really great!   However, it can result in
        significant non-interoperability issues.   (cf. Forslund and Kilman, The Impact of the Global, Extensible Electronic Health Record
        in   "Managing Healthcare Information Systems with Web-Enabled Technologies", ed. Lauren Eder,
        Idea Group Publishing, 2000 pp 3-13).  There is a tension between having "everyone do their own thing" to facilitate
        the enormous creativity of mankind and to have coordinated efforts so that information can be integrated
        where appropriate.  Perhaps integration is not achievable with the enormously diverse approaches
        to the important problems we are facing.  I have viewed the web (perhaps erroneously) as primarily
        the presentation layer  (and human interaction layer) of the Internet with many other ways that applications can talk to one other
        rather than through web protocols.  Perhaps this adds more complexity, but it provides even more flexibility as
        we seek to build a global infrastructure which can enhance the way mankind works together.   Unfortunately,
        it may take more agreements between people than are practical.    It is also possible that the security
        problems the web and internet faces today my drive one to better agreements and solutions.

        Thanks!

        Dave

        
        --- Sean McGrath <sean.mcgrath@...> wrote:
          
        David,
        
        I''ve skipped over a large part of your reply. I think we have
        exhausted 
        the topic. I understand what you are saying. Time to just agree to 
        disagreeI think.
        
        
            
        I don't see this is the antithesis of SOA at all.   As indicated
              
        by the 
            
        Gartner report, this approach is an excellent example of SOA
        in use in real-world application environments.
              
        I'm saddened to see the term SOA used in the catch-all way it is
        being 
        used. The price of popularity I guess. If the object-centric, RPC,
        tight 
        coupling stuff takes center stage in SOA, I will be very
        disappointed. 
        Perhaps I'm on the wrong list :-)
        
        regards,
        Sean
        
        
        
        ------------------------ Yahoo! Groups Sponsor
        
        To unsubscribe from this group, send an email to:
        service-orientated-architecture-unsubscribe@yahoogroups.com
        
         
        
        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/ 
        
        
            
        
        =====
        Take care.
        Kaleem. 
        "Democracy gives equal opportunities, Communism gives equal share." -- my Theory of Everything (http://kaleem_aziz.tripod.com/blogs.html).
        
        __________________________________
        Do you Yahoo!?
        SBC Yahoo! DSL - Now only $29.95 per month!
        http://sbc.yahoo.com
        
        
        ------------------------ Yahoo! Groups Sponsor ---------------------~-->
        Save up to 80% on top-quality inkjet cartridges and get your order fast!
        FREE shipping on orders $50 or more to the US & Canada. Shop at Myinks.com!
        http://www.c1tracking.com/l.asp?cid=5511
        http://us.click.yahoo.com/v2G7ND/KfUGAA/ySSFAA/NhFolB/TM
        ---------------------------------------------------------------------~->
        
        To unsubscribe from this group, send an email to:
        service-orientated-architecture-unsubscribe@yahoogroups.com
        
         
        
        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
        
        
          

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