iPod snobs?

This article in the New York Press, talks about the all too often human psyche of jealousy.

"THE BLINDING WHITE cords flowing out of my sublimely waxed ears say it all: I'm in no mood for talking, and my income bracket makes cumbersome CDs so unnecessary, so Second Wave. With thousands of songs from my iPod at my polished fingertips, I can now walk through life effortlessly, angelically, shielded by the anodized aluminum of my futuristic listening device. I can strut with confidence and disinterest past those in my chosen path. I'm cut off from your dirty world by my ear buds and their enhanced sound and noise-suppression features. I'm a creature of advertising, a walking cliche with 25-minute skip protection and Volkswagen dreams. Shit, my profile even resembles the faceless, platonic form in the billboard."

I mean, give me a break!... I take great offence that we iPod'ians should be marginalised as some sort of fashion conscious, Sunday Times reading, urbanite clique.

Were not Volkswagen drivers, we don't wink when we see another iPod'ian on the train.

Im sorry, the only reason they moan about people who have iPod's, (heh heh, im gonna say it), is because they can't affort one! I feel a whole lot better now. :)

I can think of a few people that fit this particular quote! :-)

"He may look like an idiot and talk like an idiot but don't let that fool you. He really is an idiot." - Groucho Marx

BluePod - Apple Rendezvous & Wifi

I have seen the future and i believe this small Eastern-European software company has cracked it...

They taken the Apple Rendezvous presence protocol and ported it on to .NET/Pocket PC through Wifi.

Perrsonally i would have liked to seen support for GPRS and Bluetooth, rather that Wi-fi, since they are more pervasive....

check out the article..

IT-Analysis.com

So Don

I noticed this little snippet from Don Boxs spoutlet...

Earlier this week, I wanted to install a significant piece of Microsoft software on my machine. The first step of the setup program was not "Install" but rather "Plan." When I selected that step, I was prompted by a ~100K HTML file with all of the prereqs, QFEs and side effects I needed to understand before installing. Given that I have almost no additional time nor room in my brain to process this data, I opted to not install the software and instead dedicate that time to letting the product manager know why "he lost me at hello." Hopefully it will get fixed.

Is it me or is he getting just a little bit irritated with the pre-reqs for installing BizTalk 2004?

Of course this is all just speculation.... :-)

How to learn about BizTalk 2004

People have been dropping me e-mails asking me what is the best way to get into BizTalk and how to learn it.... My advice is to stop reading blogs, and start playing with the code! Only kidding!

To that end the i would highly recommend downloading the newly updated BizTalk 2004 SDK. There are loads of examples that include (orchestrations convering compensation, adapter patterns including the SQL adapter, using the BAM API, invoking the Business Rules engine, Custom Pipelines, building custom Functoids, creating WMI scripts). Its a fantastic resource, so get your head buried in that stuff and you'll be fine...


Also to reduce anyones day-to-day stress, its worth keeping an eye on the Microsooft Knowledge Base for known issues with BizTalk 2004.

Also MSDN has posted some new articles on process integration using BizTalk 2004 and service-oriented integration

More deliberations around Bus topology with BizTalk

Scoott Woodgate has posted an excellent whitepaper that describes the guts of BizTalk 2004, particularly around the architecture of the MessageBox and Logical Hosts.

The question i posed to Scott, was that within the context of subscriptions, how does this 'BizTalk Group' or 'MessageBox network' work across an enterprise WAN? My earlier understanding came down to how practical will it be run a globally distributed MessageBox architecture, are there latency issues that make this unworkable, and therefore we need look other multi-cast approaches to delivering an ESB?

From a BizTalk perspective does that mean we have no choice, but to employ Zonal BizTalk Groups, and all the implications that go with that from an Operational/Admin/Routing point of view.

thoughts please...

Groove Networks

I haven't blogged about Groove Networks, which is strange since its a real cool technology, and ive been watching it on and off for the last 3 years... Actually i remember using it way back when the first beta came out, though the problem back then was that machines were not powerful enough for the task, unlike today.

Anyway, Groove have come out with Groove 3.0 (beta), and well, i reckon they have taken a very great technology (way ahead of anything Microsoft has currently or will have in the next 5 years) and made its even more pervasive with the way it integrates into Windows.

Check here for a quick review on the product. I really ought to get more excited about this technology in my blog (it deserves it), though lately my excitement has been mostly on BizTalk 2004.

A Danish poem

"The noble art of losing face may one day save the human race". I like that quote, i really do.

XML Web Services in BizTalk 2004

Joe Klug from Microsoft, had lots of new snippets on the Web Services support in BizTalk 2004 server:

1. Publishing a Web Service
Through the BizTalk Web Services Publishing Wizard.
(i) expose an orchestration or a schema as a Web Service.
(ii) support of unknown SOAP headers.

2. Consuming a Web Service
Add Web Reference
(i) through this you can re-use and aggregate existing Web Services.

3. SOAP Headers
- SOAP Headers are supported for published and consumed web services. A known SOAP header is as defined in the WSDL, and unknown headers are sent in message but not defined in the WSDL (so BizTalk wouldn't know about them), and aren't supported when consuming a web service.

4. WSDL extension
- WSDL Extension - supports 2 SOAP extensions. You can replace the schema defined within the WSDL; this is useful since due to a limitation in the current version of ASP.NET (will be fixed in Whidbey) the generated file can produce some loss of information during the class conversion (e.g. maxOccurs and minOccurs).

5. Type-Agnostic Ports
- BizTalk 2004 allows for the creation of Type-Agnostic ports which is a port that can receive any type of XML document:-
(i) Its means that the Message type is an XML Document (System.XML.XMLDocument .NET namespace)
(ii) Such a document could also be a multi-part message type.

Here is a pattern of how you could abstract the web services layer across all your BizTalk subscriptions.

(i) You could create a dummy orchestration using this type-agnostic port which receives and sends a XML document.
(ii) You could publish it as a web service, but never actually deploy that orchestration.
(iii) You could create multiple orchestrations that subscribe to different types of message, but only have single web service receive point for multiple different message types.

6. WSE Adapter for BizTalk 2004
- Hopefully by the end of 2Q2004 (Beta in Feb/March) Microsoft will release a WSE Adapter for BizTalk 2004. This will be based on WSE 2.0, and be fully configured through policy assertions rather than code. WSE standards for Web Services Extensions, and provides a mechanism to deliver a product-grade Web Services stack that can be used across server Operating Systems and products. Since OS release-cycles occur every 3-4 years, WSE contains the latest Web Services specifications. Therefore this BizTalk adapter will piggyback on the WSE life-cycle, and will very likely become the future 'Indigo' adapter for BizTalk. There will need be some form of migration from WSE to the Indigo Message bus (can't say Indigo!)

7. SSO confusion in Sharepoint and BizTalk 2004
- Microsoft BizTalk 2004 Server and SharePoint both employ different solutions for Single-Sign On (SSO), from what is understood SharePoint will change its SSO solution to support BizTalk. It will be possible to generate BTS SSO tickets when using Web Services (SOAP headers).

Microsoft are in the process of writing a whitepaper to clarify this all, since architecturally its a bit confusing that there are different approaches to SSO, including an agreement between the two product groups going forward about supporting a 'Single' single sign-on solution (well done Microsoft - duh!)

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)

WinFS - Why its a big deal..

The following snippet from Ray Ozzie succinctly sums up why he reckongs WinFS is a big deal. These things take time, but WinFS will open up some really fascinating changes that we can expect in the next 5 years (or so). The 'network-effect' of WinFS, assuming we end up ubiquitously storing primary schemas types about at least our identities and profiles, means we will be able to do some pretty amazing things with personal communication and collaboration. Searching my digital assets, (i.e music, photos, documents) against standard schemas that make cross-referencing, searching and inferencing of my content, and content that i am interested in, extremely easy. IMHO, this makes WinFS the most significant part of Longhorn.

"No - the "big deal" about WinFS IMHO isn't Search. Like Web Services - it's about the fact that it's an attempt to get a higher level of interoperability between programs through agreement on schemas. Hopefully, toward the goal of bootstrapping network effects, and unintended/innovative consequences, on the client. WinFS defines an extensible object model and persistence mechanism, as well a rich and extensible "relationship" mechanism that can be used to intertwingle objects with that are somehow related to one another. Some kinds of stock relationships are obvious: common Author, common Artist, common Location, common Priority, etc. Some may be more subtle or domain-specific: common Project, common Client, common Contributors, or even manual and thus not-easily-described ties." More....