Remote Object References and Web Services

Discussions

News: Remote Object References and Web Services

  1. Are the concepts of a remote object reference still applicable for Web Services? Jorgen Thelin, Chief Architect of CapeConnect shows how remote object references are best avoided when using XML Web Services due to the fundamental mismatch between the service oriented middleware approach of Web Services and the object oriented middleware required to support a remote reference architecture.

    Read Web Services and Remote References.

    Threaded Messages (19)

  2. This article articulates well some of the complications inherent in distributed object middleware which are greatly simplified by Web Services. However, coordinating loosely-coupled services into applications that you can manage and monitor when deployed is not made any easier. The model for building these applications does not exist yet and is still at the architect's mercy. The implication is that when the architect is moving to a new project, the application, you guessed it, becomes legacy and is generally difficult to maintain in production and very difficult to adapt. With time, these problems should and will be addressed by a new type of container and a development abstraction that are especially tailored for orchestrating web services.
  3. I generally agree with the article. The CORBA notion of a remote factory issuing remote references is contrary to what Web Services are trying to achieve, and that is a style of a single-request-in, single-response-out. Attempt to invoke a web service with a minimum of round-trips.

    I like to use a use-case analysis on a problem, and then attempt to implement each use case as a single request-response pair. In addition to avoiding the remote reference problem, this solution scales well because it allows the servers to be stateless, and therefore easily replicable.

    The developer is getting some help in this regard. The request interceptor concept from CORBA is showing up in WSDL as separate attachment objects that get copied into the composite document by handlers outbound and extracted from the document by a matching handler inbound (see Apached Axis for more info).

    I disagree that the architecture of web service is being done in an ad hoc manner and that it will become unmaintainable legacy when the architect moves on. On the contrary, the WSDL definition contains a complete schema definition for each component, making the request-response message pair the best documentation of the service. I admit that this is still a bit fuzzy in the specs, but you can see a clear direction, and that is: SEND A COPY, NOT A REFERENCE.
  4. The architecture of web services, i.e. their self-describing interface, is well designed. However, the architect building process-centric applications using loosely-coupled services as building blocks, especially when asynchronous communication is involved, still has a lot of infrastructure work to do. Also, there is no model in existance yet for programming process logic using such components, i.e. orchestration logic. Hence, architects end up designing state machines and other event-driven frameworks which are built as a custom one-off for each project. I believe there is a need to address this challenge in the same way that application servers addressed the challenge of writing custom CGIs.
  5. Orchestration logic is available in J2EE servers now or will be very soon (< 6 months) from all the major vendors. WSAD and WAS 5 have a lot of support for these types of scenario.

    It's just not part of the J2EE spec but there are various efforts happening aimed at standardizing orchestration logic.

    Maybe J2EE 1.5 will have orchestration APIs, who knows.

    Billy
  6. Um. So this artical is basically saying, ur, don't use distribute OO technology. OK, thats easy! Hurray, the world is starting to agree with me that it creates issues that simple are not needed.... long argument to back up all that stuff.

    So, we are left with... request... response. Nice one.

    Orchestration logic? Is this to do with ordering, retries, failures and so on. I.e. your standard 7 layer protocol model stuff. Why do I suddenly get a sinking feeling.

    What exactly is the problem that web services is solving? Is it 'documenting the RPC call'. Is so, then thats silly. Loads of ways to do that.

    Is it 'making the protocol readable'. ie using ascii streams... slow and revolting, but I guess it removes protocol analysis.

    Is it, UDDI stuff. Come on, why does anyone use dynamic lookup. You know what you want to use and you use it. Dynamic anything is useful to maybe 1 in 1000000000 projects, and only then because the software boys are bored out of their heads. And because the security boys haven't been consulted.

    Web Serverices... a new RPC mechanism. Thats the long and short of it. Or maybe 'a new, slow, cross language rpc mechanism'. I guess thats fair.

    Jonathan
    ps If you actually know a good reason please do say, I am interested, and would honestly like to see a point to this latest 'last best hope for (techie) mankind'.
  7. Jonathan Gibbons writes:
    "Web Serverices... a new RPC mechanism. Thats the long and short of it. Or maybe 'a new, slow, cross language rpc mechanism'. I guess thats fair."

    New, slow, asynchronous, cross-language rps able to handle flexible data model with standard XML tools?

    Joanathan, there are a lot of situations where end to end performance is not of the essence. Offloading cycles from the client is important, but it doesn't matter whether the request is serviced in 1 second or 10 minutes. Thus far there have been two basic choices in EAI mechanisms, incompatible ORB's (COM+ and CORBA or RMI), and slightly less incompatible MOM tools. The ORB's are synchronous and the MOM's (mostly) asynchronous.

    The ORB's were not well-suited to large data models and not suited to asynchronous architectures. The MOM's were best-suited to publish-subscribe (broadcast) architectures and better (though not perfectly) suited to large data models.

    SOAP solves many of these problems, enabling large and varying data models over an asynchronous link. SOAP also allows full cross-platform communication without laborious cross-ORB integration and without installing (and paying for) an MOM product.
  8. Web Services can help solve a number of different problems, one of the most important of which is: Business Process Integration. Of the various ways to address the latter, Web Services holds great promise, not the least of which is changing the economics of integration and blurring the lines between application development and integration. A direct consequence of utilizing Web Services for addressing Business Process Integration is the notion of Orchestration Logic. You're dealing with managing asynchronous conversations with loosely-coupled services in addition to supporting effectively the existing tightly-coupled programming model. The suggestion is a JSP-like abstraction for orchestration logic in conjunction with an orchestration container. The orchestration container leverages reliable communication infrastructure and run-time environment for coordinating, managing and monitoring such applications. This enables delivery of collaborative and transactional business processes with strict adherance to interoperability standards, a readily available developer community (Java) and a new level of manageability.
  9. Jonathan you sound a very interesting guy, and also the few who dare to understand and challenge what's going on. I just would like to add one more thing, remote referencing is not just a problem of generating a 32 bit id and passing it from server to client some where in WSDL,like the one mentioned in the paper. I bet there are very few people who really understand the problem and the reason behind it (So far no GC algorthim scale well on WAN based environment). Untill the "Masters" behind the Web Services don't find any solution, we will hear from lot of experts not to use remote references in Web Services, the day they find the solution, passing references between the services would become a very viable solution. I love the fuzzy world of programming....
  10. Jonathan Gibbons wrote:
    > Web Serverices... a new RPC mechanism.
    > Or maybe 'a new, slow, cross language rpc mechanism'.

    What you are describing here is "RPC remoting using SOAP" in my mind, which is not the same as web services.

    Web services to me are about loosely coupled interfaces and loosely coupled invocations, while RPC remoting is inherently about tightly coupled interfaces and tightly coupled invocations.

    The really important thing with web services (to me at least) is not the SOAP or even the WSDL, but the XML Schema representation of the data model involved in the interactions - ie. the "payload standard". That is what both ends need to agree on first, and the web services interfaces and the WSDL follow second as a standardized way to represent and describe the interactions down to the wire level (in a manner that can be used across any number of operating systems and programming languages).
    I think we are already seeing this trend in the industry at large - as vertical market schemas such as OTA (travel) or HL7 (healthcare) are starting to become firmly established.
    This is where the real value of web services starts to show through, and not by simply sending RMI calls over port 80 by encoding them as SOAP.
  11. Jorgen Thelin writes:

    "Web services to me are about loosely coupled interfaces and loosely coupled invocations, while RPC remoting is inherently about tightly coupled interfaces and tightly coupled invocations."

    Yes, that is what I have been getting as well. You can certainly closely model an RPC if you wish, but the framework is a lot more flexible than that.

    "The really important thing with web services (to me at least) is not the SOAP or even the WSDL, but the XML Schema representation of the data model involved in the interactions - ie. the "payload standard". That is what both ends need to agree on first, and the web services interfaces and the WSDL follow second as a standardized way to represent and describe the interactions down to the wire level (in a manner that can be used across any number of operating systems and programming languages).
    I think we are already seeing this trend in the industry at large - as vertical market schemas such as OTA (travel) or HL7 (healthcare) are starting to become firmly established.
    This is where the real value of web services starts to show through, and not by simply sending RMI calls over port 80 by encoding them as SOAP."

    You could set up a parser which would kick off multiple operations (possibly multiple web services, API calls, RMI calls, XSL transformations, or what have you) from the single web service depending on what is encapsulated in the payload of that one XML document. The format of the XML document inside ther SOAP document can vary a good deal between requests, so you are gaining a good deal of flexiblity which you don't have in ORBs in the web services model.

    BTW, well designed MOM apps have a good deal of flexibility as well.
     
  12. He was very brief explaining the alternative to remote object references. Guess you have to pay the 10 bucks to get the full picture!
  13. This is a little confusing. It seems to me to be obvious that Web Services are by defintion stateless, so what is the point? I suppose that one could design a web service (or rather a series of web services) which return a reference and then are referred to it by a further call for a web service from a client. But unless the data requirements are crushing why would one wish to do this?

    Assuming an enormous data load I would think the problem decomposes into several web services, an activation service which carries the full information load and returns a reference (and persists the state somehow), and one or more services which take the reference as an argument and does something. But this would be exceedingly rare I would think. Much more likely would be the wrapper architecture which treats the entire interaction as a single stateless web service?

    So what is the point of the article? That one should not model a web service (or indeed a session EJB) directly as an underlying ORB call? That seems deafingly obvious to me.
    Perhaps I am missing something?
  14. I'm not going to be fair here, and just quote a couple of lines from the posts:

    "New, slow, asynchronous, cross-language rps able to handle flexible data model with standard XML tools? ....SOAP solves many of these problems, enabling large and varying data models over an asynchronous link."

    "changing the economics of integration and blurring the lines between application development and integration"

    "So what is the point of the article? That one should not model a web service (or indeed a session EJB) directly as an underlying ORB call? That seems deafingly obvious to me.
    Perhaps I am missing something?"

    I agree with all of this. And I'm happy to use XML as a way of sending java variables. I remember reading about project Brazil.. co-operating web servers.. and thinking that was 'cool'. BUT. I do not believe SOAP and web services are the savior of integration. Nor are they open, nor are they standard. In exactly the same way that xml is not open or standard. It comes down to the data model - either in a database, in an xml document or in a soap call.

    And integration is about making different data models work. Either at the api level, comms level or db level.

    Java RMI is a dang site easier to code... but even if soap reaches the same ease of programming.. so what. Soap replaces RMI. I'm happy with that, but fundamentally why does anyone care how the information is sent?

    So I come back to:
    soap is a slow cross language rpc mechanism.

    OK, fine, I'm happy.

    Orchistration logic is basically application development. ie the bit that makes this app different from every other. The bit that programmers do. Call it software dev, OOA/D/P, or whatever. There is no fundamental good within soap to reduce the problem complexity. Asynch systems are a complete swine, and they will remain so. This is how people work... try asking your purchasing dept to do something... its exactly that problem. In fact its worse, because at least people have the same schema (mostly) - your soap based systems all use a different api (xml schema).

    Jonathan
  15. "BUT. I do not believe SOAP and web services are the savior of integration. Nor are they open, nor are they standard. In exactly the same way that xml is not open or standard. It comes down to the data model - either in a database, in an xml document or in a soap call."

    If you're looking for Reverend Don the SOAP savior you've come to the wrong church.... ;-)

    "Java RMI is a dang site easier to code... but even if soap reaches the same ease of programming.. so what. Soap replaces RMI. I'm happy with that, but fundamentally why does anyone care how the information is sent?"

    Go ahead and use RMI if all you want to talk to is Java. Use RMI/IIOP if all you want to talk to is CORBA. But SOAP has one big advantage: The ability to deliver a high-value payload to Microsoft applications and vice versa.
  16. Hi Don,

    OK, I'll use soap (sometimes).. another line to the CV. A colleague suggests using database links instead, ODBC, JDBC, with SQL being the cross platform, cross language comms... Its way more flexible that wrapping your business data in masses of soap API's. Even has built in security, and integration with loads of dev tools... Also has a huge programmer base and requires zero infrastructure. And this is what you have to argue against, in terms of dev cost, deployment cost, maintenance and staffing costs.

    What soap has in its favour is that Microsoft loves it, and so it will be cheap and the dev base will ramp up quickly.

    Jonathan
  17. Don Stadler wrote:
    > I suppose that one could design a web service
    > (or rather a series of web services) which return
    > a reference and then are referred to it by a further
    > call for a web service from a client.

    What you are describing here Don is a "handle" token, rather than a "remote object reference" pre se.
    A handle is an opaque data token that can be passed back and forth for the purposes of correlating several calls (such as a session ID, for example).
    A remote object reference is something you have to reconstruct and re-instantiate on the client to be able to make use of, to create a local instantiation (proxy) for the remote object.

    > But unless the data requirements are crushing why
    > would one wish to do this?

    "Handle tokens" as you describe are typically used for session tracking or transaction correlation purposes.
    They do add extra complexity to an application architecture, but sometimes they are vital.

    There use is entirely different from the use of remote object references (in my mind at least).


    The point here is that in the same way that we all had to adapt our application design patterns when we moved from using local data objects to remote data objects (eg. EJB Entity Beans) by adopting such things as the "value object" design pattern to avoid the constant network calls for each field, in the same way the jump from current distributed object frameworks to web services require us to re-examine our architecture and design patterns checklist and recognise that some of the old practices don't fit well in the service oriented middleware world of web services.

    That is not to say that you can't still use the old programming techniques over a SOAP transport, just that that is "RPC remoting using SOAP" and not "web services".

  18. What you are describing here Don is a "handle" token, rather than a "remote object reference" pre se.

    Ok. So it is something like a JINI proxy object?

  19. > > What you are describing here Don is a "handle" token, rather than a "remote object reference" pre se.

    > Ok. So it is something like a JINI proxy object?

    A remote object reference is, yes.
  20. So if a remote object reference is like a Jini proxy, why would one wish to model it directly via a web service?

    I could see data modeling an entire session and wrapping the session with a stateless web service, but doing a series of web services to operate a remote object interactively with a client would seem rather clutzy to me. Why not obtain the remote object reference directly at the client and manipulate it there. Or if a firewall or something intervense, then wrap it.