The New Face of the Silicon Age

Another piece of commentary from Wired magazine, which talks about globalization and outsourcing of IT jobs, and how India's dominance in the knowledge-based 21st Century is causing plight for the pissed-off programmer.

...Some US firms now outsource their PowerPoint presentations to India, a blow to the pride of managers everywhere. From this perspective, India looks like an artificial intelligence, the superbrain that never arrived in silico. No wonder workers tremble... .. .

. .. ...The Bhagavad Gita opens with two armies facing each other across a field of battle. One of the warriors is Prince Arjuna, who discovers that his charioteer is the Hindu god Krishna. The book relates the dialog between the god and the warrior - about how to survive and, more important, how to live. One stanza seems apt in this moment of fear and discontent. "Your very nature will drive you to fight," Lord Krishna tells Arjuna. "The only choice is what to fight against." Read more from Wired Magazine....

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.

BizTalk 2004 is starting to heat up...!

Just received the Release Candidate on BizTalk 2004 (BTSEvalRC - 74367-000-0000007-05479). It sure has been tidied up. Not only that, but there seems to be generally more chatter on the forums and with a lot more material popping up.

Anyway this entry will be a placeholder of references (heres a few for starters):-

• BizTalk PowerToys from luke nyswonger.
  
• El Grego ( i don't know his name) has a sample which shows how to use the Enterprise Instrument Framework to generate an application event (in this case a suspended message caused by a send port retry failure). Although BizTalk generates a plethora of WMI events that can be picked up by MOM (and NetIQ soon).
  
• Martijn Hoogendoorn has a Suspended Queue Listener Windows Service which basically listens out for the WMI event and allows you to then do what you want with it... It works in real-time and batch mode as well... Get it here.
  
• Brian Loesgens has some cool code that implements service windows for send/receive locations. Get it here.
  
• Stephan Bouillon has a real cool component that replaces the standard XML validator used in the BizTalk default pipeline. Rather than the standard behaviour of suspending the message it sends an error to the messagebox, this allows you to have a error handling orchestration that can subsribe to these messages... This greatly improves the end-to-end management of BizTalk, product team why did you not think about this!!?!
  
• Another bright chap Stephen Thomas has some interesting pieces on sequential convoying, etc...
  
• Jeff Lynch is doing some pretty harcore mapping examples, especially around conditional outputs for linenumbers.
  
• Giles Zunino has a good example of how you can archive any messages as they are passing through the BizTalk pipeline. This i see as a standard service that ought to be provided by BizTalk, and perhaps through HAT you can achieve this. However companies may have compliance issues which deem the need for a more legally watertight solution. Anyhow something that i had been thinking about also.
  
• The Core Engineering team from the Biztalk product team are now getting on the case, this really does raise the quality of information coming out. No other vendor can match this openness. Well done Kevin B Smith and Lou Graber
  
• Jan Thielens Blog has some good best practices on BizTalk 2004, particularly around foundation components like error logging, exceptionstions, and XML dis-assembly (since the product documentation only covers CSV)
• Mike Holdorf's been keeping it real with some pains and best practices on BizTalk.
  
• Charles Young from Solidsoft has some interesting articles on BizTalk Orchestrations and Transactions.
  
• Carlo Poli has is having some fun with versioning BizTalk assemblies over here...
  
• A new book on BizTalk 2004 development on Amazon.
  
• Another Christoph has some development learnings on using BizTalk orchestrations.
  
• The Middleware company has released a .NET community for serverside, enterprise specialists, its called strangely enough, theServerside.NET!!
  
• Some early ideas on naming standards for BizTalk orchestrations.
  
• Scott Woodgate who is the programme manager of the BizTalk Server / Jupiter Programme.
  
• An interesting presentation from Claesen Christof on BizTalk 2004 and how it can be used as a Enterprise Service Bus. And another on a simple and easy BizTalk 2004 overview.
  
• Darren Jefford is having some fun with MSMQT and MSI Exception handling at his blog over here.. way to go!
  
• The gotdotnet community has a number of code samples and its own special workspace for BizTalk.
  
• Mike Woods has his own msn workspace which include the hands on labs that was available at TechEd and PDC.
  
• You can find many of the presentations and videos from the PDC 2003 here . (its only here for 6 months so hurry!)
  
• You can find many of the presentations and videos from the various TechEds 2003 here.
  
• Benjamin Mitchell has some interesting things to say regarding Indigo, BizTalk and Yukon (Service broker). More on his comments later.
  
• Microsoft's BizTalk 2004 beta newsgroup.
  
• Microsofts BizTalk public newgroup on all things BizTalk.
  
  More to come soon...

P900 and playing DVD ( using MPEG4)

This is a fantastic example of what you can do with the new Sony Ericsson P900. Its built in MP4 player (actually the p800 has this too, but not a great screen) allows you to play a full-length movie.

To do this, you will need to rip (from dvd to mpeg), encode (convert to mp4), and transfer (to memory stick)