RE: The Two Way Web

Hi Mark and Ken,

	reading your last messages, it seems to me that you face the problem 
under different angles.

Let's see if, with this message, I increase the confusion or I can
contribute positevely. 

	BTW, in this message I express my own opinion which do not engage 
	anybodyelse than myself.

The goal is to try to re-position the discussion in the context of the
business needs/requirements instead than in the context of the technical
definitions.

1.	It is important to access "high-level" functionalities on remote
	systems. By "high-level" I have in mind a "service level" model,
	where I invoke a "functionality" which is provided remotely	
	by something.

	There are many ways to do this : RPC, Corba, Java, DCOM etc.

	Each of these technologies make it "difficult" to manage some 
	aspect of the whole problem (security, platform dependency etc...)

2.	RPC or OO ?
	I have been discussing this issue in other situations and, again, I
	hope not to mis-target the problem.

	The RPC approach assumes that you know the "entry point" of a given
	library, in some way. The library can be statically linked,
	dynamically linked or remotely accessed.

	The OO approach assumes you execute an action on a given object. The
	object can be local or brokered somewhere else, doesn't matter.

	A part from the obvious advantages of an OO approach, at the end,
	we are talking about executing "function calls" (do not misunderstand 
	me here, I am talking about the advantages of OO...)

3.	Now, the game is to make different systems (software systems) which do not
	know each other talking together. These systems are different because of 
	platforms, of languages and technologies. 

	What I need is to establish a communication among them in the less invasive 
	way I could imagine and in the quickest way I can.
		- less invasive : I cannot sometimes change the installed products
		  nor I can add some additional layers because the target machine
		  will never support it..
		- quickest : the business requires integration as a differentiating
		  factor. I need to serve my users (jnternal or external) "now"

	So, a "unified" way of talking is required.

4.	IMHO, the most simple way to provide this "unified way of talking" is
	by exposing "ENTRY POINTS" corresponding to the "FUNCTIONALITIES" I need 
	to access on a different system. 
	I do not care, here, of Set/Get in the OO way. Maybe the functionality I want
	to expose (and, on the other side, I want to use) is just Set/Get of an
	object property...or maybe is starting a CICS Transactions.

	Here we are talking BUSINESS. When I say this, I say that the granularity 
	is defined by the business and not by us technical people.

	If I expose "Entry Points", the most natural way of doing is, IMHO,
	by exposing "method signatures" since the "context information" is made
	clear to the interface and not assumed to be in some particular state.
	One of the constraint is, in fact, to be LESS INVASIVE AS POSSIBLE on the
	system where you are executing the service; it should be seen AS MUCH AS
	POSSIBLE as a BLACK BOX. 

5.	Of course, there are already a lot of implementations of this architecture
	in the current systems. Look at Corba, at DCOM etc. 
	But here we are talking about SYSTEMS THAT  have NOT been thought to talk
	together since the beginning and of solutions that involve different 
	technologies WHICH MAY CHANGE RAPIDLY over time (I mean, an integration solution
	should be seen as a LEGO, where I can quickly change the layout to obtain
	a different picture. Business calls this "flexibility").

6.	So, XML may be a very good way for defining the "Entry Point" level conversation.	
	I do not enter in this discussion, of course. I think we all assume that XML
	is significantly important in this domain.

	There may be different ways of defining "interfaces to other sstems" using XML.
	Roughly, IMHO, there is a "Data/Business Oriented Way" and a "Technical Oriented Way".

	The "Data/Business Oriented Way" is the approach followed by the Schema Orgs 
	(BizTalk, Oasis, RosettaNet). The assumption is that someone is able to 
	describe/model a given Business and to provide a "business view" of the interaction 
	between different systems. There will be some "intelligence" which will interpret 
	a DOM into the relevant software calls etc.

	The "Technical Oriented Way" is the approach followed by XML-RPC and SOAP. 
	I consider this approach MORE TACTICAL (opposed to the previous one which is 
	more STRATEGICAL since involves some BPR) but is very suited to "include" in the
	integrated solution things that you KNOW BY ENTRY POINT (so, virtually, everything).

	It is very simple to describe any API (or, even, Object methods) in terms of
	function calls with parameters.

7.	HTTP is, according to me, a different side of the coin. 
	It is an answer to the question : Once I have the "serialization", what is the
	transport ?

	HTTP is "AN" answer, NOT "THE" answer to the question. 
	The answer depends not only on the question BUT also on the context where you operate.

	Perhaps you operate in a context where reliable messaging is required. In this
	case, probably, HTTP is not the best technology.

	Again, here the answer will be biased by the business use of the solution.

8.	For this reason, what is important is to define ways where systems can talk 
	together in the context that makes more sense.

	As to HTTP, I may need to access a foreign system through the standard HTTP
	server. Or, maybe, I may think that I want the "external system" to play the role
	of a very little http server...or a message server...

	Ideally, IMHO, the protocol (SOAP, XML-RPC etc) should be independent of the
	transport. In this way, the same "RPC-enabled" system will be able to
	play in different integration scenarios.


Sorry if I added more confusion. 

Best regards

/Stefano

Received on Tuesday, 14 March 2000 04:11:39 UTC