OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-msg] Short proposal


Attached is an updated copy of the proposal.

-Matt

Doug Bunting wrote:

> Matt,
>
> Your use cases sound to me like they need two default CPA documents or 
> descriptions rather than one.  At one level, the Messaging TC would 
> need to describe / define the environment in which the Interrogation 
> Service runs.  At another, the service (MSH) receiving an 
> Interrogation Request must have an appropriate Interrogation Response 
> available, meaning it must have the default CPA (where you've focused 
> this proposal).  Getting both levels nailed down may be slightly less 
> straightforward than your proposal implies.
>
> I'd guess deciding the parameter set for executing an anonymous 
> Interrogation Request will form the bulk of the development work for 
> our TC.  The actual Interrogation Request / Response would likely be 
> relatively simple.
>
> Small point: My preference would be for the receiving service, using 
> information available in the Request, to respond with a fully 
> qualified CPA rather than having us attempt description of "something 
> (random) between a CPP and a CPA".  The Request shouldn't be anonymous 
> but "merely" be un-authenticated.
>
> thanx,
>     doug
>
> --On Wednesday, 19 February 2003 15:20 -0800 Matthew MacKenzie 
> <matt@mac-kenzie.net> wrote:
>
> > Team,
> >
> > Attached is a short proposal I just wrote describing in a little more
> > detail the idea I brought forward in the conference call today.
> > Basically, I'm proposing a new service which will return to the 
> requestor
> > the "default CPA".  I'd like to hear any comments on this.  I've cc'ed
> > Duane Nickull, to get the ebArchitecture opinion on the "anonymous" use
> > case.
> >
> > Regards,
> >
> > Matt


Title: MSH Interrogation Service Proposal

MSH Interrogation Service Proposal

OASIS ebXML Messaging TC

Matthew MacKenzie

XML Global Technologies, Inc.

Abstract

This paper proposes a new system service, which when used in conjunction with a Default CPA, will allow anonymous clients to see which services are exposed and available for use by anonymous .


Introduction

The concept of a Default CPA has been bouncing around the ebXML Messaging TC for a number of months. To some, "Default CPA" really just means "Default CPA Id", plus some well known configuration variables to allow the Ping and StatusRequest services to be accessed outside of a formalized collaboration agreement. To others, this author included, the idea of a "Default CPA" is very concrete. The default CPA should actually be a fully formed ebXML CPA, with one PartyInfo having correct party configuration information, and the other PartyInfo referring to a party with a PartyId identifying it as a magic anonymous user.

If a default CPA as above is in place, it would be advantageous for the MSH to export a service which would be capable of communicating what CollaborationRoles are available to anonymous clients. In the author's opinion, this anonymous boot strapping capability opens ebXML Messaging up to a more broad range of possible applications.

Use Cases for the MSH Interrogation Service

Below are a collection of use cases that are meant to give a clear picture of what the MSH Interrogation Service would be used for.

Ping and Status Request

Using the MSH Interrogation Service, a trading partner could determine whether another trading partner supports Pings or Status Requests early on in the relationship, allowing it to seamlessly offer enhanced services to its client applications.

System Service Modularity

With an MSH Interrogation Service, system services can be added to a MSH without the intervention of the ebXML Messaging TC. Example system services that may be added in this fashion is a CPA Negotiation service or an Apache HTTPD-esque system-status interface.

Processes with an Application or Registration stage

Some internet-based business processes may require a user/organization to go through an application or registration process prior to being permitted into the system. An Application service could be exposed to anonymous users in the Default CPA, and exposes via the MSH Interrogation Service.

Adding the Interrogation Service to the Specification

The service itself is quite straight forward. A brief section will be needed to explain a better researched version of the following information.

A valid ebXML Message is sent to the MSH in question with the following parameters set:

  1. Service set to urn:oasis:tc:ebxml-msg:service:interrogation

The response will contain:

  1. Service set to urn:oasis:tc:ebxml-msg:service:interrogation

  2. The first attachment will contain the Default CPA.

Incorporation Target

This proposal is targetted at the 3.0 version of the ebXML Messaging specification, however, there is no reason why the service could not be incorporated into a 2.x implementation of the ebXML Messaging specification.

The bulk of the work that the TC would need to undertake in order to adopt this proposal would be in the definition of the basic settings required to access this service. It goes without saying that requiring the use of a "Default default CPA" to govern the interrogation is contrary to the core reason for this proposal. The MSH Interrogation Service must be accessable without much configuration on the client side.

To facilitate connection to the MSH Interrogation Service, the following configuration values or setting should be assumed:

  1. Use sychronous HTTP transport only. No SSL Client authentication.

  2. No acknowledgements requested or sent.

  3. No duplicate elimination requested or complied with.

  4. No non-repudiation.

Variations & Permutations

Interrogating for WSDL

The Action could be used to signal the format of the returned document, which COULD be either a WSDL instance or a CPA instance.

Default CPA Built Dynamically from Request Supplied Info

Suggestion by Doug Bunting

Instead of defining an "anonymous" party, a possible approach is to have the MSH Interrogation request contain a CPP instance for the requestor. The Interrogation Service would then return a CPA with both the MSH's PartyInfo as well as the PartyInfo supplied by the requestor.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC