IP notes and Draft

IBM WS Notification, WS Resource Spec. Jan. 20, 2004

  • Chapter 2 covers the new IBM/ WebService and GridComputing Spec. for WS Notification and WS Resource declaring the distinction between "Service" and "Resources" as a "separation of concern" like you see in Aspects. Chapter 5 covers detailed process and operations on the new WS-Resource entities as they participate in Web Services.
  • The Spec. above as a basis for B2BPO to claim a canonical and "unique business process"
  • B2B implementation of Channel Data Commands (CDC) as canonical use of WS Resources
  • CDC's are mobile, descriptive resources collaborating with the CORE B2BPO service which gets Connections and moves Data between nodes located at different companies linked in a Virtual BPN over the Internet.
  • When an Atomic unit of data as described in a specific CDC has to move from company A to Company B, and when those Companies both host the B2BPO distributed service, the following conditions apply:
    • as a precurosor to the connect and move "transaction" operating on the actual shared data, using standard B2BPO messaging service, the CDC may be sent to either company A or Company B for "consumption" by a B2BPO service daemon
    • The CDC is an abstract description of properties and State information which can be "bootstrapped" into a "do this B2BPO Work" context at either company's node in the Virtual BPN
    • When this particular CDC is consumed by a Node on company B, the bootstrapped context conveys the following semantic:
      • "you are a data subscriber on messaging topic "xyz"
      • "you are to Get a connection to company A " on the Protocol from the Context
      • you are to issue "pull" or "get" instructions
      • command actions will move the Remote data at Company A to "yourself"
    • Now switch the consumption context and assume the very same unit of work were to be done by consuming the very same CDC on Company A's node rather than on company B's node.
    • Now, on company A, the very same CDC's state and property information as used in the bootstrapped context conveys the semantic below:
      • "you are a data publisher on messaging topic "xyz"
      • "Get a connection to company B " on Protocol "xyz"
      • issue "push" or "put" instructions operating on the local data
      • command actions will move data over to the Company B node
  • So what's the Claim being made by B2BPO?
    • Specific , unique collection of state, properties as designed in a CDC
    • Unique design of Context engine that collaborates with the CDC in order to:
    • bootstrap a Virtual and Mobil Context that in turn collaborates with:
    • The B2BPO service engine and the private file systems on member company's servers in order to share data on a Virtual BPN running over the Internet
    • Object Design Diagram here for much more detailed message patterns and sequence
  • Analogy to fictional Amazon Scenario canonicalized to fit WS Resources spec.
    • Service is an Catalog Item Purchase requiring 3 Resources
    • Resource 1 is an ISBN number identifying the book in according to a universal Item Identity or UPC
    • Resource 2 is a .NET Passport OR, the Globally Unique ID of the user, The Principal owner of resource #3
    • Resource 3 is the virtual wallet
    • Scenario:
    • Any browsed book Catalog belonging to any Vendor, or any Reader-related affinity group can be the source of the ISBN number, while clik-thru agreements assure connectivity to Amazon with associated buy now link
    • The "buy now" action focuses the browser on the Amazon Service Catalog Item Purchase , while the now virtualized external WS Resources #1 - #3 have been "dragged" along
    • The canonical Definition of Catalog Item Purchase references 3 WS Resource entries
    • The Service implementation marshalls the 3 resources
    • Book Purchase Transaction completed by Amazon service
    • Note the user never manually navigated the Amazon Catalog of books, nor was any manual action required to "cross-reference" the ISBN ID to an Amazon Book ID.
    • Note the benefit of the role of externalized WS Resourcesis that the Core Amazon Catalog Item Purchaseinteroperates with any canonical implementation of the 3 Required Resources

PO sends Mapped XML StreamSource per Topic Subscription and XSLT Context

This process entails a unique combination of specific behaviors of public Java API's, achieving an efficient, flexible combination of shared B2B processing goals including data transport and delivery, wire encoding, serialization, de-serialization, and reformatting according to a customer specific data format.

Given that the following 4 objects are serializable and encodible one would then be able to bundle them inside a message like a SOAP ENVELOPE and move them on a Business Process Network (BPN) so that they when they arrive at any node or locale in a B2B Processing Network they render their distributable XML data in the preferred format used by that Subscriber at that particular locale:

  1. a command processor with a Runnable Interface that performs useful work in conjunction with the other objects by transforming the sender's XML data for the receiver according to the XSLT Template. Run logic uses the template to operate on the XML data producing as a result an implementation of transform.stream package like StreamResult. Encapsulating the XML conversion process, the RUN method operates transparently at either node in the BPN. Prior to putting the SOAP envelope on the wire, the Sender's Pipeline Chain may call run for the conversion, then the XML data format changes from SENDER Schema to Receiver Schema. Subsequent calls to RUN by the receiving system after the SOAP envelope arrives on that BPN Node will NO-OP due to the state information in the context object -Transformed=TRUE.

    review this .. do you want serializable procedural logic , or do you want to be conservative, limiting distributed properties to just data and context info? The conservative design needs another deployment option as this class must be deployed on all nodes (WebStart).
  2. a block of data in an object that implements a hi-level API for Java data sources. Usually this will be XML conforming to the command processor's data interface and a class implementing the XML Data Source interface like SAXSource or StreamSource.
  3. a conversion template object that is a member of a specific XML Transform API -XSL Template.
  4. a processing context for the actual Transformation senses the locale, controlling the behavior of the Runnable interface that does the data conversion.



    The Runnable interfaces introduce the ability to drop one of these compound objects mentioned above on a processing icon. During development, this means that a programmer just constructs this compound object without worrying about the default Transformer Factory or anything. What is transparent in this type of architecture is the actual location of the client ie was the client requesting the transformation of data on my machine or on your machine. Again, it doesn't matter.

Definition of Terms

An XSLT Context or transformation context is a software object with properties whose values direct a computing process using data transformation functionality to convert XML data elements from a Schema or specific data structure expression preferred by Company A into a different data structure or Schema preferred by Company B. The process uses an XML data source or input to produce an XML data target or output using a template - the template is a collection of rules expressions from an XML transformation language API. Transformations are activities implemented in a number of software APIs designed for XML that reformat entities within the data source using a template to map input data to an XML data target having specific data structure organization meeting the requirements for subsequent downstream processing by the target.

A Topic Subcription is an associative data entity relationship binding a user to a Topic - a user in a role of Subscriber to a Topic receives any data published by a data producer after being bound to the topic.

A StreamSource within the javax.xml.transform.stream Package is a Java API Class implementing the XML Data Source, whose features include 3 critical components of the process addressed in this application:

  1. streams may be used as input to a standard transformation ( XSLT ). Converts from an XML view preferred by Company A to a separate view for Company B
  2. stream may be used as message component in a standard messaging protocol. An entity inside of an envelope that whose properties assure its collaboration with messaging API features ( (de)serialization, encoding, wire-transport )
  3. streams may be pipelined or layered. In a sequential workflow, output streams from one activity can be input streams to subsequent activities.
In light of the above components, it's possible to refine the process description for the Mapped XML StreamSource software object that gets sent from Company A to Company B. Its a conversion process with 2 layered streams - 1 for input as an expression of company A's data preferences, the 2nd as output expressing the different Data Schema of company B. The other component is the conversion process, sitting between the 2 layered streams. The conversion component is a standard API conversion process using normal inputs and outputs for an XSLT translation.



As a way of envisioning the Object, think of a pipe that has a stream inside and in the middle of the stream is a process. When its on the wire, the stream is an instance of a base64-encoded byte Array. At the pipe's endpoints the views into the actual data are different, due to the XSLT activity that occurs in mid-stream. The stream's input side contains raw data from Company A. On the output side of the Stream, the data is different, conforming to Company B's map.

The Post Office (PO) is an implementation of a message handler and manager that directs messages by using the message Topic to retreive Subscriber lists. The end to end sequence is summarized below:

PO receives data on a topic
PO looks up subscribers to that topic in a DB
**Patent stuff really starts here**
For each subscriber:
 - getMappedTemplate(forThis Subscriber)
 - getContext(forThis Transformation)
 - Transform the data when RUN is called
 - serialize and encode the data for transport
 - send the data along the wire