"Indigo" for Linux

Paul Freemantle, a work associate back in the days... has now left IBM and has co-founded a new Web Services Infrastructure company called WSO2. -- "Oxygenating the Web Services platform".

No, this is not Web 2.0, its not AJAX, its not Google, its not about Ad Revenues! -- Its all about enterprise plumbing grunt that is supposed to miraculously work in the background.

Perhaps its harsh to use the term "Indigo for Linux" -- but im sure the world needs higher level frameworks than what is provided by WS-*.

In fact many of the founders of WSO2 helped contribute to many of the WS-* standards and Apache stacks. There purpose, they claim, is more ambitious than delivering "Indigo" for Linux, it is to build a Web Services platform "which treats Web services as first class components instead of as a facade to some existing platform like J2EE". Hmm... im a bit behind on whats going with Apache projects -- but is there a workflow/orchestration framework?

Check out more here on Apache Axis 2 the follow up to Apache SOAP.

Google Desktop

Google has a cunning way of keeping their little ideas slowly creep up on you.... We'd all heard about the Google Search desktop.. looks like its arrived!


This site here provides more information on their ambitions beyond just search... (e.g. gBrowser).

Following on from what a few people have been saying regarding Googles strategy a couple of things are probably clear now:

- They will leverage their vast knowlede of Global Internet Server infrastructure.

- They are focused on building Service Oriented Applications (this means server-side apps)

- If they do venture into the Browser space, it will be tightly integrated through all their server side applications (Search, Gmail, Picasso/Hello, Blogger, Google News, Google Groups) using XML Web Services.

- Their own cookie-based authentication works across applications.

Well all this leads me to believe that if they do extend Gbrowser (they may build it via a Web Services layer) that exposes this via a Mozilla type application.

Ive even heard one person say that Google are going to create a rebranded version of Mozilla/Firefox that integrates Google apps re-written in XUL instead of HTML. XUL is essentially an XML-based UI language that allows you to describe Windows-like user interfaces in XML.

This would allow Google to develop browser-based network-centric applications that have rich UI functionality that web developers only dream about. Think about it...

BizTalk 2004 and Microsoft position on ESB and Indigo

Below is some discussion about Microsofts definition on what is or isn't an ESB, and how that relates to BizTalk 2004. Included are some comments from Don Box on Indigo, and how Indigo fits in with the SOA model. Scott Woodgate then pitches in on the BizTalk strategy to leverage the underlying platform. And how this will continue in the future with the support of Indigo adapters for cross enterprise connectivity.

This thread appeared (although its not there now) on microsofts public forums microsoft.public.windows.developer.winfx.indigo and first reported by winfx247.com

Question/
Will this still be a function of BizTalk and if so how will you guys reposition BizTalk from EAI to ESB. As I understand it Indigo will serve as a message bus, I think it will be important for you guys to soon make it clear what you plans are in this area.

Answer/
Don Box [MSFT] (VIP)
I'm not sure what ESB is, but here's the Indigo/BTS story.

Indigo can work with existing BTS implementations in that they both support SOAP and WSDL.

The version of BTS after Jupiter will use Indigo directly. This brings Indigo's security, RM, and TX stack to BTS.

DB

----- Marlon Smith wrote: -----

Will this still be a function of BizTalk and if so how will you guys reposition BizTalk from EAI to ESB. As I understand it Indigo will serve as a message bus, I think it will be important for you guys to soon make it clear what you plans are in this area.

Christian Weyer
I guess by ESB he means Enterprise Service Bus ... just like adding a new
word to the SOA buzzword bingo :-)
http://www.cbdiforum.com/public/news/index.php3?id=1326

Cheers,
--
Christian Weyer
[Microsoft Regional Director, Germany]
[MVP ASP.NET & XML Web Services]

** XML Web Services: http://www.xmlwebservices.cc/
** Weblog: http://weblogs.asp.net/cweyer/

"Don Box [MSFT]" wrote in message
news:52D46B5F-B004-4BE6-BB3F-63168434F7F5@microsoft.com...
[Original message clipped]

a message bus, I think it will be important for you guys to soon make it
clear what you plans are in this area.

--
Christian Weyer
[Microsoft Regional Director, Germany]
[MVP ASP.NET & XML Web Services]

** XML Web Services: http://www.xmlwebservices.cc/
** Weblog: http://weblogs.asp.net/cweyer/
--
Scott Woodgate \(MS\)
--
I'll jump into this thread as the BizTalk guy. What Don says is correct but
I'd like to break it down for everyone:

- Indigo provides support for secure, reliable, transacted "web" services
which is obviously pretty important :)

- Indigo unifies ASP.NET, DCOM, COM+ etc. This point is important because
today BizTalk Server 2004 uses ASP.NET ASMX APIs under the covers for its
web services support (we didn't build our own WS stack we leveraged the one
in the platform and provided value add infrastructure around it for
transformations, graphical point and click etc.) and tommorrow we will
transition those APIs to Indigo

- Indigo is a transport in the terminology of BizTalk Server (just as MSMQ,
MQSeries, Web Services)

- Because Indigo is a transport and BizTalk Server has an extensible adapter
framework for transports (application or technology) I demonstrated a
prototype at PDC an "Indigo" adapter (cf. the Web Service adapter we use
today). Adapter is probably a funny word to use its just the generic point
in the architecture to plugin transport support the support will be native
in the next generation in the "Longhorn" timeframe when Indigo ships.

- Adding to that Indigo is an API (not a set of tools). One of the cool
things BTS2004 provides even in an all "web services" environment is super
rich tracking infrastructure and a variety of design/management tools.

- BTS2004 will continue to support heterogeneous "messaging" <- which is an
overloaded word in case you didn't notice microsoft message queuing does
messaging biztalk server does "messaging" they are different but related
things, same thing with indigo which provides the migration path from msmq
and biztalk server, and of course orchestration/workflow moving further
forward (and a bunch of other innovations :))

- BizTalk Server will continue to support EAI, I'll dodge the ESB point
because there are various analyst interpretations there, and SOA as it
does in 2004 in the future obviously enhanced with the underlying platform
that Indigo provides.

My PDC presentation for those who are interested is at
http://blogs.gotdotnet.com/scottwoo. I'll probably put up a video of the
demo in the next few days. The important thing here is that both BizTalk
Server and Indigo are innovating together to move forward the platform and
the server in the "Longhorn" timeframe and your investment in BizTalk Server
2004 is a strong investment to move forward.

Cheers,
Scott.


--
Scott Woodgate \(MS\) (VIP)
--
From a BizTalk Server perspective we are all about leveraging what is in the
platform and then adding value on top of it. As these lower level management
features/functionalities become available in the platform we will leverage
(and actually in some cases enhance them directly) and continue to innovate
on top of them.

Cheers,
Scott.

BizTalk and Publish/Subscribe, EAI and the Enterprise Service Bus concept

So every-1 is talking about enterprise service bus architectures (basically pub/subscribe) and how that is a more cost effective and easier approach to EAI than the traditional hub/spoke model. Well first off, the notion of an ESB was first banded around by Sonic Software (of SonicMQ fame), and then legitimised by Gartner and more recently by IBM. Sonic have a product called Sonic ESB that they believe differentiates them from the traditional EAI vendors.

Their definition of an ESB as i could understand it is that it must have the following characteristics:-
- must be a 1st generation product (i.e. built after 2000)
- it must be built from the ground-up using XML, XSD, XSLT standards.
- MOM(asynch, pub/sub, store & forward) / Transformation / Content based routing.
- Highly connected (e.g. Web Services / J2EE)
- Monitoring (Helath and Activity Tracking)
- Distributed deployment.
- Single point of management / control.
- Location / Technology transparency.
- Fault Avoidance (ease-of-use) / Fault Tolerance (intelligent routing) / Redundancy.

In simple terms here is how ive differentiated ESB and EAI.
ESB - Simple intelligent routing, distributed peer-based architecture.
EAI - MOM, explicit routing, central hub, service broker.

On the face of things it looks like BizTalk 2004 has a lot of these features, but im not yet sure that BizTalk has a fully distributed deployment architecture that provides location transparency and a single point of management, i may be wrong - ( im just writing my current thoughts!), but i think the issue may related to how you can distribute BizTalk servers across an enterprise with multiple data-centers (over a WAN).

BizTalk 2004 has the concept of a BizTalk group (a domain or federated group in other words), which is effectively the scope for Administration, Routing, Message Tracking and all other services. All related BizTalk receive and processing servers are part of this scope. All servers within a particulary BizTalk group use the same MessageBox. This is an important point, since how and where you deploy your servers are impacted on the fact of the single MessageBox design.

Lets think about this, once a message is received (through the Receive Port and Receive Pipeline) it ends up in the MessageBox (where any meta-data like promoted properties of the schema are stored). Any interested parties ( whether its a map, rules engine, an orchestration or even a send port/pipeline) can subscribe to that message.

The MessageBox relies completely on SQL sever for its persistence, and since BizTalk does have a scale-out story by having multiple MessageBoxes (you still need to have a master MessageBox database - i am planning to test this.) you may be able to deploy those MessageBoxes in a distributed manner, although im not sure that is its primary design. I assume that it was designed to improve the scalability of the primary Master MessageBox. In any case there are better ways of improving the scalability, namely scale-up SQL Server (more on this later).

So BizTalk allows you to have multiple MessagesBoxes, you may be able to distribute these across the enterprise (although this may not be its primary design, and may introduce considerable latency issues), but assuming it does, it means that all the distributed BizTalk receive/processing servers can be part of a single BizTalk Group, and if that is the case you get the complete benefits of location transparency, and a single point of management.

Web services, SOA and Service Bus architectures

This is an interesting article which talks about the roles of Web Services, Services Oriented Architectures (SOA), and the role of EAI.

I have to say that there is a lot new thinking in this area, which a lot of vendors are struggling to come to terms with, its far from clear, many have a legacy to protect, and a vision that they need to articulate.

With all of this, its too easy to look at nirvana and think that we will someday be connected in this enterprise-galactic glue of process managed asynchronous messaging that is location, technology, and vendor transparent!

Whats clear, is that the ideas are much further ahead than where most enterprises in reality are at.