On SOA, Indigo and Services

A Failure to Communicate

Message for you, sir! — Tue, 10 May 2005 05:12:16 GMT

On Attribute-Based Programming Models

Brain.Save() — Tue, 10 May 2005 08:57:30 GMT

re: On SOA, Indigo and Services

Jochen Fromm — Tue, 10 May 2005 12:54:48 GMT

OO and SO are not a contradiction. SO encapsulates OO. Functions can be used to create objects and objects to create services. Another form of programming are agents: agents can be used to create societies, but they need a suitable environment.

A message-oriented view of the world is not new. Windows is a message-oriented OS, which was originally not object-oriented at all. The core of each program for Microsoft Windows is the message loop: while (!GetMessage(...)) { ProcessMessage(...) }

In the OO view, messages are "replaced" and described by events, event-handling and delegation. In modern integrated development environments like Visual Studio you do not see the underlying messages, you only edit events and event handlers.

Many attempts of the Web Services Acronym Hell, BPEL or BPEL4WS, BPDM, BPMN, BPML, WSFL, WSCI, WSCL and WS-CDL were meant to enable SO programming, through web services composition and orchestration. Yet there is no common standard, and even a common standard does not solve all problems.

Most approaches for the modeling or creation of business process workflows have a drawback: they focus on cross- and inter-organizational workflows. It is doubtful that mobile agents or information will easily move across many organizational borders, or that completely new forms of virtual enterprises will suddenly emerge out of the "sea of services" on the Internet.

An Evening of Indigo with David Chappell in Washington, DC

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems — Sat, 14 May 2005 19:03:00 GMT

An Evening of Indigo with David Chappell in Washington, DC

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems — Sat, 14 May 2005 19:03:42 GMT

re: On SOA, Indigo and Services

That Other Dude — Mon, 16 May 2005 14:39:59 GMT

What constitutes an SOA?

A simplistic architecture that might come "close" to this is an unnamed company that has operations around the world and field technicians around the world. These field technicians work in a disconnected manner. They launch a ClickOnce application which connects to their lan and retrieve information from a web service that they need. This information m ay include information about operations what they do and also includes information about how the application will function - so the application is somewhat upgradeable and extensible without actually deploying a new update.

They then disconnect and go out into the field using this inforamtion and collecting more information. When they come back they reconnect and submit their data to web services so that the data can be validated and joined with the rest of the system.

Does this sound like a simple SOA ?

To my understanding of SOA while being extremely simple this would be the basics of an SOA.

Some of the biggest hurdles in something like this is that often times data structures that are used by both ends contain shared logic which is encapsulated in objects which represent the information. Of course with web services this shared logic is not capable of happening and thus you are forced to rewrite the logic and use wrapper objects which for lack of better terminology have to be wrapped over data passed through the web service.

Is this a scenario that is better resolved with .NET Remoting? I would honestly probably be the last person to accurately tell you whether it was or not. For this SOA web services were chosen because of the quick realization of a communication and interoption. The limitation of only using HTTP, working with multiple platforms which inclue mobile devices and the need to work in a disconnected model helped put the push towards Web service as opposed to using something else.