RE: Business Service Interface

[Stefano POGLIANI <stefano.pogliani@Sun.COM>]

Marty,

	thanks for the mail (sorry for my late answer but I have been out of office).

Indeed the BPF slides you provide are covering the same area as the BSI description
I posted. The challenge is, now, being able to capture these inputs
and the powerful comments from the other members of the list and consolidate them
in a document that could be accepted as a basis for discussion.

Please find, embedded, the answers to your comments.

Best regards

/Stefano

> 
> The BSI is highly desirable for new ebXML-aware applications as well as for
> legacy applications.  The reason is that most of its functions provide
> essential services even to new applications.

	certainly this is what I think. I meant this when I wrote:

	"The BSI is not mandatory, but it is logically necessary to accommodate 
	the basic functionalities described below".

	The BSI layer should be present everywhere an Application (new or old)
	needs to participate in an ebXML context. The BSI Layer is NOT JUST a
	Technical Passive layer, but adds behaviour to the Application and makes
	sure this behaviour is consistent with the ebXML specifications and is
	interoperable with other inplementations.

> 
> IDEAS TO BE DEVELOPED (page 7):
> 
> The BSI should provide essential conversation-based services. The actual
> start and end of a conversation are application-dependent, so the BSI's
> interface to the application should provide for indicating start and end of
> conversation.  See the IBM tpaML proposal for discussions of the
> conversation.

	My idea was to "define" a Conversation object which has its own lifecycle
	within the BSI and could, eventually, be persisted (for receoverability 
	and/or for scalability [a sort of swap]).

	I am not sure I understand and/or agree with the fact that conversations
	are application-dependent. I think that, in a general model, conversations
	may even not require interfacing the Application world but could be
	in the position of "taking decisions" by themselves (based, for instance,
	on information found in the envelope/header (environment information) 
	or, why not?, in the payload itself (stop this conversation and start
	the other when the content of the tag is > 100 USD...).

	This would, probably, require an extension of the Transformation layer.
	What I mean is that the Tr Layer could be "programmed" to dynamically
	load modules or stylesheets which could "help" in that.

> 
> A given BSI should definitely support concurrent conversations as a
> performance enhancement. An alternative view is that a BSI is an
> instantiation of one conversation and a B2B server should be able to run
> many BSI's concurrent.  In that case, starting a conversation 
> invokes a new BSI.

	from a design point of view, I would prefer to separate the
	BSI from the Conversation and having the BSI able to manage
	multiple conversations in parallel.
		Parallel conversations may be required both to support
		multiple "clients" (where each client runs its own
		statefull conversation independently on the others) and
		to support "switching" within the same client (where
		some rule make a sub-conversation start whilst keeping
		the main one active).
> 
> I prefer that a conversation always be started by an API call from the
> application.

	see my point previously. I would say that the conversation is
	started by the BSI. The BSI may be "triggered" by the Application
	or, in some cases, be triggered by the "rules".
> 
> Maintaining the conversation state is an essential service of the BSI.  It
> can maintain the state in a conventional database.

	Indeed. What is important is to "avoid" to bind to a specific DB
	and to provide the "interface"/"message defs" that allow an
	interoperable use of the stored informations.

	What I mean is that the SMEs may not be forced to buy an expensive
	DBMS and could implement some of these things in flat files for instance.

> 
> Regards,
> Marty
> 
> (See attached file: bpf.pdf)
> 
> ******************************************************************
> *******************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> *******************
> 
> 
> 
> Stefano POGLIANI <stefano.pogliani@sun.com> on 10/18/2000 09:15:53 AM
> 
> Please respond to stefano.pogliani@sun.com
> 
> To:   ebxml-tp@lists.ebxml.org
> cc:
> Subject:  Business Service Interface
> 
> 
> 
> 
> I have started to  collect some ideas on the Business Service Interface
> (BSI).
> These ideas were  mainly derived from some thoughts I had on this subject
> and from the discussions  during the f2f last week.
> At the moment,  please consider this as a contribution to the discussion.
> 
> Attached, find a  word document with two gifs for the pictures.
> 
> Best  regards
> 
> /Stefano
> 
> 
> 
> 
> 
> 
>