Java Web Services Architecture: JAX-RPC, SOA, Transaction Mgmt


News: Java Web Services Architecture: JAX-RPC, SOA, Transaction Mgmt

  1. Learn about JAX-RPC, Service-Oriented Architecture and Transaction Management from chapters excerpted from 'Java Web Services Architecture'. 'JAX-RPC' looks at the JAX-RPC service model, data types and serialization. The SOA chapter examines SOA entities, and interface design for services. 'Transaction Management' introduces fundamental transaction concepts and looks at WS Transactions.

    Read chapters on JAX-RPC, Service-Oriented Architecture, and Transaction Management

    Threaded Messages (9)

  2. I downloaded the chapters and read the customer reviews on
    Quite an interesting read. Seems like a worthwhile book to have.
  3. Runtime binding[ Go to top ]

    The chapter on Service Oriented Architecture expresses the possibility and the goal of elliminating any compile time binding between consumers and services. Here is a snippet ...

    " Using a pointer from the registry entry, the consumer then binds to the provider of the service. The description of the service consistes of all the arguments necessary to execute the service. The consuer formats a request message with the data, based on the description provided by the directory pointer.

          The consumer then binds the message to a transport type that the service expects and sends .... The only dependency between the producer and the consumer is the contract, which the third-party registry provides. The dependency is a runtime dependency and not a compile-time dependency. All the information the consumer needs about the service is obtained and used at runtime. "

    For very simple situations I can see how this will work, credit card processing for example. You have a few very well defined arguments that need to be supplied to such a service. More complicated services whose arguments may change over time are a different story. The consumer has to have a way to obtain the necessary arguments required by a service. This implies a degree of compile time knowledge or at the least design time knowledge.

    I feel that the idea is expressed so matter of factly in this chapter as well as in other publications that maybe I am missing something. I would love to hear from someone who has implemented an architecture like this. I want to understand how they were able to interact using mostly runtime bindings to systems which did not have well defined interfaces that were available to them during development.

    Appreciate any insights ...

  4. Runtime binding[ Go to top ]

    "..has to have a way to obtain the necessary arguments required by a service. >This implies a degree of compile time knowledge or at the least design time >knowledge"

    Not really. What this requires is some sort of "a-priori contract". Usually this is established though well defined service level agreements. We used runtime bindings ,which I might add have been so well explained in this book, to transparently switch over the location when the service was brought down. I belive some other folks used this approach for versioning purposes. As a note runtime binding doesnt inherently imply that the registry is queried for ever service invocation.
  5. Runtime binding[ Go to top ]

    The word "binds" or "binding" is the root cause of confusions.

    The first "binds" is the binding of "Port Types – an abstract set of operations supported by one or more endpoints."

    second "binds" is binding of "Port – a single endpoint defined as a combination of a binding and a network address" or "Binding – a concrete protocol and data format specification for a particular port type"

    Correct me if I'm wrong, the bind that you are looking for, is the binding of parameters in "Port Types". If this is the case then it is not the scope of WS-I profile.

    And you are correct, that at least you need to have a knowledge about the exposed API. And most probably Credit Card Org. is building this already like what's happening to ebXML - touted to replace EDI.
  6. Runtime binding - why?[ Go to top ]

    And you are correct, that at least you need to have a knowledge about the exposed API. And most probably Credit Card Org. is building this already like what's happening to ebXML - touted to replace EDI.

    Or of the exposed documents. Which is a far more natural way to think about flexible, changing and version dependent APIs than simple SOAP-RPC is. This being true, I have found that real Runtime binding to services is only suitable if there is a lot of fast change on both sides of the application. Typical examples used to trading terminal applications in brokerage companies, where client (and server) application are (or at least used to be) fast moving targets with nightly builds momving into production right away on some seats while other seats retained older application versions.

    On the other hand I have seen little use for runtime binding in "normal" applications. Just the opposite is true: To orchestrate a realiably working application of loosely coupled parts it is necessary to understand what the application parts are doing and what characteristics they have well beyond WSDL level or even document structure level (transaction, redoability, idempotency and so on). One way to deal with this is to blow up WSDL to include every possible metadata, which is basically what BPEL4WS, WSCI etc. are aiming at.

    The other way is to assemble with care and "by hand". This may cost you some flexibility but will sure gain performance and reliability. And it has another upside: When using full blown BPEL2WS or similar, you will end up with some "distributed transaction model", for example WS-transaction or what have you. Experience with 2PC architecture has shown, that distributed transactions on a large scale inevitably destabilize an application. I have seen this dozens of times happening yet people just don't understand why this literally *must* happen. So I prefer people not being tempted in the first place to mess around with distributed transactions :-)
  7. On page 329 it reads:
    >> "In document/literal style, the contents between <SOAP-ENC:Body>
    >> and </SOAP-ENC:Body> are sent as an XML string to the application,
    >> which is responsible for parsing the XML."
    Also on page 333 it reads:
    >> "In general, however, the effort and complexity involved in document
    >> style service is greater than for RPC style..."

    This information is incorrect. First -- it uses the wrong namespace
    prefix -- it should be SOAP-ENV rather than SOAP-ENC. Second,
    document/literal does not mandate that the SOAP payload be delivered as a
    string, nor does it require the application to parse the XML. The message
    style (RPC/Encoded versus Document/Literal) simply defines the format of the
    message on the wire, and it really has nothing to do with the programming
    model. A JAX-RPC implementation should be able to automatically marshal both
    formats. If you prefer to let your application parse the XML, you can return
    the data as a string, but it's not required. JAX-RPC should be able to
    return document/literal data as Java objects. In fact, from a programming
    point of view, the only difference that you should see between RPC/encoded
    versus doc/literal is a configuration setting or generation switch.

    The chapter is correct when it says that RPC messages cannot be validated
    using an XML Schema -- which I view as a major draw-back to RPC messages.

    My advice is to always use doc/literal. The WS-I Basic Profile disallows the
    use of SOAP encoding, therefore you shouldn't use RPC/encoded. (SOAP
    encoding was designed as a stop-gap measure in the original SOAP spec
    because XML Schema wasn't final. Now that XML Schema is final, we really
    don't need SOAP encoding anymore.) The JAX-RPC spec doesn't require support
    for RPC/Literal, and lots of systems don't support RPC/Literal, therefore
    you shouldn't use RPC/Literal. So that only leaves Document/Literal.

  8. What else will the soap payload be delivered as ? It as to be
    a string- even if its base64 encoded.

    While it may be true that from the programming perspective you dont
    do anything explicit true that from a programming perspective
    you dont do anything explicit, someone has to parse the XML...even
    if its the JAX-RPC RI that does that.
    How else will it convert the xml into the Java object ?

    Also now since youre passing XML, dont you also need to define the schema for
    that on your own -isnt that complexity ?

  9. Also does it matter if SOAP-ENC or SOAP-ENV is used if the namespace is decalred correctly ?

    I notied that JWSDP uses <env:Body> and <soap-env:Body> both.
  10. Errors and typos[ Go to top ]

    I have been noticing typos throughout the book. Does anyone know of an errata on the web? Publisher's site comes up empty.