1. Requirements
   
2. Business Process and Information Meta Model
   
3. Core Components
   
4. Registry and Repository
   
5. Trading Partner Information
6. Messaging Services

• http://www.ebxml.org

• Identification
• Authentication (verification of identity)
• Authorization (access controls)
• Privacy (encryption)
• Integrity (message signing)
• Non-repudiation
• Logging

• Send   send an ebXML Message   values for the parameters are derived from the ebXML Message Headers
• Receive   indicates willingness to receive an ebXML Message.
• Notify   provides notification of expected and unexpected events.
• Inquire   provides a method of querying the status of the particular ebXML Message interchange.
  

• MessageHeader Element
• From & To Elements
• Service Element
• Action Element
• MessageData Element
• Manifest Element // holds one or more reference elements identifying payload data

• Business Process Specification in XML -  http://ebxml.org/specs/ebBPSS.xml
• Business Process Specification in XML -  http://ebxml.org/specs/ebBPSS.xsd

The JAXM Messaging Provider

A 'remote provider', a.k.a, 'a messaging provider', may be thought of as
a messaging server. From a SOAP perspecitve the messaging provider
is acting as a SOAP intermediary. The following quote from the release
documentation is key feature supplied by the JAXM messaging framework.

The messaging provider will contiuously attempt to deliver any messages
that the client application has sent and to receive any incoming messages
that have been addressed to the client. The event that triggers a message
provider to send stored messages, will typically be the establishment of
a connection to the remote provider. The JAXM release notes state that
"All messages sent through a remote provider are logged for perusal later."

// something like a Internet provider will pass on messages once a mail
// client has established a connection. If the connection is active the
// message will be forwarded as received

Review of a SAAJ Synchronous Message Exchange 

To summarize in diagrams, recall the our earlier discussions and examples
of SAAJ synchronous request / response model. In brief, a SOAP message
is created, or passed into the program, a URL object representing an endpoint
is created and a  message is sent via a SOAP connection supplied by a
SOAPConnection factory.

The recipient extracted data from the incoming SOAP message, processed
it in some way and created a new SOAP response message which was returned
as the response part of the original HTTP call. This was accomplished by
overriding the JAXM servlet's onMessage( ) method.

SAAJ Synchronous Messaging Model

Client       >-- sends SOAP request --->       Receiver
Client (waits)   < -- response returned ----<  Receiver

The JAXM Asynchronous Model

The JAXM asynchronous model adds an intermediary stage allowing
asynchrous, one-way messaging to occur. Enhancements like, message
acknowledgements, reliable message delivery and  'away from home' access
are also possible using the JAXM asynchronous messaging model.

JAXM  Asynchronous  Messaging Model

Sender                               Receiver  
  |                                     |
Provider                             Provider
  |_______ <SOAP / HTTP Connection> ____|

A messaging provider is continuously active. The provider stays in the wait
state ready to receive any messages intended for it's client. It also will store
and forward any messages it client sends to it. In addition to resending
unsuccessful messages, the provider generates error messages as needed
and maintains a log to record messages and relevant error messages. A
JAXM application that uses a Provider can act in both roles, as client and
server, sender or receiver.

 Following is a possible set of activities that describe how a messaging
provider works.

"The JAXM provider administration tool allows users to make changes to the
provider configuration. It is expected that the main users will be Systems
Administrators, but anyone who needs to change the configuration for the
provider can use it.

Some typical ways to change the provider properties are:

• To add, modify, or delete an endpoint.
• To change the retry interval (the amount of time the provider will wait before trying to send a message again).
• To change the number of retries (the number of times the provider will try to send a message).
• To change the directory where the provider logs messages.
• To change the number of message records logged per file.

Click on "Profiles" in the navigation bar to view the default properties common to
all profiles. Click on one of the profiles to view the supported protocols. Choose a
protocol to edit properties for that profile and protocol combination."

• Endpoint         // endpoints or service targets
  
• URLEndpoint  // specialized for URLs

• OnewayListener // asynchronous, one-way messaging
  
• ReqRespListener // synchronous, request-response messaging

• JAXMServlet

• ProviderConnection
  
• ProviderConnectionFactory

• ProviderMetaData

• JAXMException

• public Endpoint( String uri )

• public void onMessage( SOAPMessage  message)

• public SOAPMessage onMessage( SOAPMessage  message )

   +--javax.servlet.GenericServlet
        |
        +--javax.servlet.http.HttpServlet
              |
              +--javax.xml.messaging.JAXMServlet

 ProviderConnectionFactory pcf = ProviderConnectionFactory.newInstance( );
      ProviderConnection con = pcf.createConnection( );


Retrieving a ProviderConnectionFactory using JNDI

In an implementation specific form, a ProviderConnectionFactory can be registered
with a naming service based on JNDI or Java Naming and Directory Interface. The
servlet or Enterprise JavaBean container in this case, manages the factory as a 
container component. The factory object will have been associated with an identifier
which can then be used to get a handle to the factory. Then an application can 
'lookup' the factory object via it's given name. In the following example, code
is shown which serves to reference the factory object. 


Example Showing Locating a Factory object using a JNDI Lookup // example from JAXM docs
 
      Context ctx = new InitialContext( );
      ProviderConnectionFactory pcf = (ProviderConnectionFactory)ctx.lookup(
                                                                 "ProviderXYZ");
      ProviderConnection con = pcf.createConnection( );


The following quote from the JAXM API documentation gives an insight into how
the messaging provider acts as a SOAP intermediary. A list of Endpoints is created
at deployment when the messaging provider is configured. 

"The messaging provider maintains a list of Endpoint objects, which is established 
at deployment time as part of configuring the messaging provider. When a client 
uses a messaging provider to send  messages, it can  send messages only to 
those parties represented by Endpoint objects in its messaging provider's list. 
This is true because the  messaging provider maps the URI for each Endpoint 
object to a URL".



ProviderMetaData

ProviderMetaData is a informational class that can be used to learn about a provider
once a connection to that provider has been made. The JAXM documentation supplies
the following example showing a ProviderMetaData object being returned and then 
version information being obtained.
 

ProviderMetaData Example     // from JAXM documentation 

   +--java.lang.Exception
              |
              +--javax.xml.soap.SOAPException
                    |
                    +--javax.xml.messaging.JAXMException

• http://java.sun.com/xml/downloads/jaxm.html
  

• javax.xml.soap  // SAAJ package
• javax.xml.messaging // JAXM package