by Donald F. Ferguson, Dennis Pilarinos,John Shewchuk

Summary: Webapplications are an extremely common application model, and they will becomeincreasingly dominant. Almost all applications in medium to large businessesoffer a Web user interface. In this article, we will use the term enterprise toencompass medium to large enterprises, and the software vendor and integratorcompanies. Desktop and client/server applications are increasingly using thebrowser for the UI engine and making calls to data and services through Webprotocols.

Software, application models and the Webitself are undergoing a revolutionary transformation. This transformation willhave as large an effect on computing as the client/server model or the initialemergence of the Web itself. The Web will evolve from connecting users toapplications provided by sites into a model in which:

·        The application executes “in the Web.”

·        End-users develop their own applications foraccessing the Web, transforming it into an end-user developed workspace foraccess to Web services.

This paper focuses on a small number ofelements of the transformation. Other papers will expand the vision.

Several technologies and trends provide theimpetus for the revolutionary transformation described above. Some examplesare: multi-core processors; virtualization; application scenarios that federatemany devices, such as mobile phones and tablets; Service-Oriented Architecture(SOA) and Web services; Web 2.0; and Software as a Service (SaaS).

We will discuss the effect of some of thesetrends, but our primary focus is SOA, Web 2.0, and Software as a Service(SaaS). These concepts and their relationships are not well understood. Thetechnologies often appear to conflict. The paper describes the elements of ahigh-level reference architecture that brings the concepts together into aconsistent whole.

Many of the preceding technology trendshave broad acceptance and awareness. This paper discusses a third trend that ismore controversial: ubiquitous programming ability. A large percentage of highschool and college graduates have basic programming skills when entering theworkforce; many students have developed simple PHP or Visual Basic applicationsand built Web sites. The professionals’ primary job responsibilities may notinclude programming, but in many cases professionals will do simple programmingif it makes them more productive. They may also develop simple applicationsbecause it is “cool.” We will use the terms end-user programming for thisconcept.

End-user programming is an extreme case ofopportunistic development, which occurs in departments and Lines of Business(LOBs) in enterprises. LOBs and teams often build simple, “quick and dirty”SharePoint or PHP applications that solve an immediate business problem byextending packaged applications or enterprise-wide core applications.

Opportunistic development contrasts withsystematic development. Systematic development is model-driven, replete withrequirements gathering, use cases and stakeholder interviews, an applicationdevelopment life cycle that includes quality and assurance, and so forth.Systematic development is the predominant model of the enterprise developmentteam (“the CIO team”). Many packaged application developers (independentsoftware vendors or ISVs) and Systems Integrators (SIs) also produce systematicsolutions.

There is a tension in enterprises betweenopportunistic development and systematic development. This tension willincrease if end-user programming becomes common. End users will not be contentto wait for the systematic development teams to develop or modify solutions.The reference architecture we describe provides an approach for reconciling theextremes of opportunistic and systematic development.

We use a scenario to illustrate thereference architecture. A core element that emerges and underpins thearchitecture is an Internet Service Bus (ISB). The reference architectureencompasses many elements, however, this paper provides detail only for theISB. Other papers will describe other elements.

Contents

The Scenario and Opportunistic and Systematic Development
Software and Services, and an Internet Service Bus
Conclusion
Resources
About the Authors

The Scenario andOpportunistic and Systematic Development

Dave travels frequently on business, anduses preferred hotels and airlines. He uses local town car services in thecities he visits and makes reservations at restaurants. Collaboration withfriends, family and colleagues is also important. Dave uses the various travelproviders’ Web sites to make and change travel plans.

Dave’s managing of trips involves a lot ofmanual tasks interacting with travel providers through their Web sites. He hasto manually coordinate tasks that span sites and cut and paste data betweenfields. There is also some sequencing logic, for example booking a restaurantreservation and car service to get to the restaurant. Dave acts like a compositeapplication or Enterprise Application Integration (EAI) solution. The manualwork is tedious and error prone. Dave has basic programming skills and decidesto write a little mashup. The mashup uses the travel providers’ Web sitesthrough client-side Web page scripting or simple HTML clipping (Figure 1(a)).The mashup makes Dave’s life a little easier and makes Dave more productive atwork because he spends less time managing his travel and more on his job. Themashup is also cool, which impresses his friends.

Mary and Ludwig like the application andget the code from Dave. They want to have different UIs but share code. So theyimprove the application by separating the UI from the Web site access,scripting, and caching by implementing a simple model-view-controller version(Figure 1(b)). The improvement also enables code reuse for access through otherdevices like PDAs or mobile phones (Figure 1(c)). Finally, they decide to movethe model layer to a department Web server and implement a simple Web application.This enables multi-person access to information, for example for assistants.

The friends have opportunistically built acomposite application, which is a simple pseudo-EAI solution. Asprogramming-capable professionals enter the workforce, these ad hoc andjust-in-time applications will become more common. There is the “cool factor”and the applications will simplify tedious tasks. Professionals may also buildthe applications “just in time” for short duration business problems, such as aconvention. The applications are analogous to the role of spreadsheets when auser performs a business task by accessing existing databases and coreenterprise applications.

Opportunistic situational applications willhave a profound effect on enterprises’ systematic application delivery. Oneeffect will be on enterprise application development. The situationalapplications may “pound on” core enterprise applications, or use the coresystems in unexpected ways. This will cause the IT organization to move some ofthe “model layer” to enterprise servers to improve performance and integrity.

In essence, the situational applicationshave defined use cases that can drive systematic enterprise applicationtransformation. The situational applications can replace simple mockups fordocumenting use cases, and can drive formal modeling.

Many pressures will move as much of thesituational applications to enterprise servers as possible. There may bepartners that need to use the application, which requires enterprise security. Someapplications may be part of important business decisions like loan approval.Governance and compliance will require logging data access and input, andsaving versions of the code for these applications. Moving the situationalapplications to the data center has profound implications. The data center willneed to support hundreds or thousands of frequently changing applications inaddition to the core business solutions. The data center needs to manage dozensof heavily loaded core application servers accessed by thousands of users, andthousands of virtual servers infrequently access by small teams using ad hocapplications.

There are many scenarios in whichsystematic solutions consume opportunistic applications. Dave will think it isvery cool if IT uses one of his applications.

In summary, opportunistic applicationsdrive systematic solutions and systematic solutions drive hardening ofopportunistic applications (for example, Representational State Transfer (REST)-> Web services). These dynamics also drive software as a service, or moreaccurately, software and services. Software and services provides a platformfor bringing together systematic and opportunistic application development anddelivery.

Figure 1: Mashup Evolution (Click on the picture for alarger image)

Software and Services, and an Internet Service Bus

Enterprise Service Bus

Consider what happens if an airline cancelsDave’s connecting flight from Dallas to San Francisco while Dave is travelingfrom New York to Dallas. Dave will not make it to San Francisco and he willneed to stay overnight in the connecting airport city. It is necessary tochange hotel, restaurant, and car service reservations. Dave could use hismashup to simplify making changes when he gets off the airplane. It would bebetter (“cooler”) if rebooking could occur automatically while he is flying.Airlines and flight monitoring sites emit feeds with flight schedule updates.Ideally, Dave’s application would be always executing somewhere “in the cloud.”The application would monitor feeds and use simple logic to react to events andchange the itinerary and plans.

It is unlikely that a simple end-userapplication could always repair the itinerary, but most repairs are oftensimple. Dave would only manually handle the complex cases, and could alsoapprove the changes his application automatically made while he was flying.

The general application scenario ofrepairing the itinerary is a common type of problem within enterprises. Similarproblems can occur for purchase orders and expense account approval, forexample. The scenario is an example of a composite application that implementsa Straight-Through-Processing (STP) pattern (see Resources). Enterprisesimplement a systematic approach to solving these problems. Figure 2 provides anoverview of what the composite application might look like if the airline,hotel, restaurant, town car and other systems were within the enterprisefirewall. A relatively long running orchestration process subscribes to eventsthat the flight management system emits. The process sends messages to/from andcalls the existing applications to cancel reservations, query availability, andmake new reservations. Enterprises are heterogeneous and the existingapplications have diverse message formats (C, COBOL, and so on) andcommunication protocols (WebSphere MQ, SAP RFC, for example).

Figure 2: An Enterprise Business Process (Click on the picture for alarger image)

The repair process design shown in Figure 2is fragile. The business process must change if another airline application isadded, for example. The business process may also be coupled to specificmessage formats and languages of the existing applications. It would bedifficult to add a general mechanism for logging messages that match certainconditions—for example, log all messages if the traveler is an executive. This fragilityhas led enterprise application architectures to evolve to an enterprise servicebus (ESB).

Figure 3 provides an overview of anenterprise service bus. Application adaptors convert existing formats andprotocols into standard Web services. This transforms the NxN protocol/formatmapping problem of connecting anything to anything into N->1 mappingproblem—that is, everything into a standard. The ESB provides additionalfunctions that process messages flowing between services. Examples include messagetransformation, logging, and routing.

Figure 3: An Enterprise Service Bus (Click on the picture for alarger image)

If the enterprise development and businessunits of Dave’s company decided that implementing his travel application wereimportant enough to fund, the enterprise team could implement an applicationsimilar to Figure 3. There are several problems with developing this systematicsolution:

1.     There is no guarantee that the enterprise wouldchoose to fund the composite application. There may be other, more pressingbusiness problems.

2.     Systematic development involves use cases, someform of process modeling, interviewing stakeholders. These take time.

3.     The airlines, hotels, and other applications areexternal to the enterprise. Enterprises are very deliberate and cautious aboutsetting up business-to-business connections. Even if the business partnerimplements Web services, the enterprise will need to establish authorizationrules and auditing for Web service interactions with partners. The enterprisewill need to support user identity management, federation, and provisioningbecause an employee will have an intra-enterprise identity and identities inthe airlines and hotels.

4.     Customizing the solution for individualemployees’ preferences is complex. The employee lacks the ability to perform“do it myself” customization. The application resides on central enterpriseservers. IT professionals define and modify the business process, not Dave.

It would be really cool if Dave could do asimple, personal version of the systematic solution. If we generalize the ESBand think of it as one type of service bus that is optimized for systematicenterprise development, we could also imagine a type of service bus that isoptimized for opportunistic development. This is the Internet Service Bus(ISB). The ISB is more like a ubiquitous fabric. The ISB links devices to eachothers, devices to local servers, Web sites to Web sites, and ESBs to ESBs, andis itself an ESB. The ISB is a platform for “do-it-yourself” compositeapplications and business processes. The ISB is also an example of Software asa Service (SaaS).

Internet Service Bus

Figure 4 provides an overview of theInternet service bus concept. (An early example of an ISB is BizTalk Services;see Resources.) An ISB provider is analogous to a PHP Web site hosting company.Both provide an application platform in the “cloud.” A PHP Web hosting siteprimarily provides a platform for developing dynamic Web sites and Web servicesthat interact with a database. In contrast, the ISB provides a platform forcreating and deploying composite applications that integrate services thatother sites provide. ISBs, PHP Web hosting companies, and storage as a servicesuch as Amazon’s S3, are examples of application enablement infrastructuresoftware as a service. This contrasts with Salesforce.com, which was initiallypackaged application software as a service.

The core ISB concept is built around aUniform Resource Identifier (URI) space. Dave’s team working on the applicationregisters and “owns” the URI http://ISB.net/DaveAndTeam. URIs below this rootrepresent application integration points, and are similar to destinations inthe Java Messaging Service, queues in message-oriented middleware, or topics inpublish/subscribe systems. The team develops an ISB application by associatingpolicy and function with URIs. The composite application is a set of URIs,policies and functions. The ISB provides an identity and access function forcontrolling which messages can be sent to a URI, and by whom. The identity andaccess function is an example of associating a policy with a URI.

For example, Dave may choose to maintain awiki page on a public Web site that shows his travel reservations. Dave willwant to control access to the wiki page. Setting up and maintainingauthentication and authorization databases at his personal Web site can betedious. The problem will become more complex if Dave has pages and data atseveral Web sites, for example:

·        His personal database driven PHP site

·        A family collaboration portal built usinghttp://www.twiki.org/

·        A presence on a spaces site like Windows LiveSpaces (http://home.services.spaces.live.com/).

Figure 4: An Internet Service Bus (Click on the picture for alarger image)

Dave’s friend Don can register with theISB’s identity component and create a user ID don@foo.bar. Dave can use the identitycomponent’s Web UI to specify which of Dave’s ISB URIs Don can access. Dave canalso define groups and grant access to the groups. Don can access the URIsafter having logged onto the ISB. The ISB simplifies Dave’s security managementbecause he can maintain a central database, and then authorize the “ISB” toaccess his wiki and other resources. The ISB protects the actual resourcesthrough access control for the ISB URIs that front them. The ISB benefit isthat there is a single space for Dave to define and maintain identities,groups, resources and access policies for all of his “services” on the Web.

We’ve just described explicit user actionsthrough Web pages. Another very common approach will be to have theapplications at endpoints participating in the composite application use Webservice APIs to access the ISB.

The identity component will also supportWS-Security’s Security Token Service (STS) functions, and federate with otherSTSs. This allows Dave to manage access for identities not registered with theISB. If foo.bar was a company that Dave trusts and implements an STS, Dave candefine access policies for identities authenticated foo.bar.

Over time, ISBs will offer additionalpolicies and implementations that can be attached to URIs. Examples may includeWS-Reliable Messaging or implicit message logging. The concept is similar toassociating quality-of-service policies with connections in message-orientedmiddleware.

The ISB builds on the identity and accesscapabilities to provide “secure universal connectivity” for applications – evenfor applications located behind firewalls. This includes support for a widerange of connectivity patterns and protocols. Examples include REST-orientedHTTP, WS-*, and the event-driven patterns found in many enterpriseapplications. Specifically the ISB’s connectivity component offers three corefunctions:

1.     Relay enables communication between the ISB andapplications behind firewalls. There are many techniques for accomplishing thiscapability (Biztalk Labs, see Resources). The relay function eliminates theneed to set up systematic cross-enterprise connections for simple scenarios.

2.     Protocol provides a set of common protocols forexchanging messages, such as WS-* or REST. The ISB also provides protocolmapping for automatically connecting endpoints using different protocols. Forexample, it is possible to connect an RSS feed to a WS-* message connectionwithout modifying either application.

3.     Functions provide support for associating simpleESB-like functions to the URL. Examples could include multicast, WS-Eventing,persistent messaging, etc.

The connectivity layer operates at theinfrastructure technology level. It simplifies solution development by removingcomplexity due to different “plumbing”—for example, REST versus WS-*. Projectsthat must implement infrastructure integration at this level incur significantcost and risk. The ISB eliminates these problems.

The connectivity layer is unaware ofapplication level elements and message formats. Building a compositeapplication requires adapting between different message formats that theconnected services implement. An example of the ISB’s functions would beconverting the parameters in an HTTP GET into elements in an XML message. TheISB offers a simple workflow (service choreography) that provides support forapplication level mapping (Figure 5).

Figure 5: ISB Message Processing (Click on the picture for alarger image)

The ISB offers a set of template“activities” for simple functions. A workflow is a graph composed ofinstantiating activity templates. Suppose that the airline emits flight statusthrough an RSS feed and part of Dave’s application expects to receiveWS-Eventing notifications for the updates. The connectivity layer supportsintegrating RSS and WS-*. It is still necessary to convert the message payloadfrom the RSS format to the XML event format that Dave’s application expects.The ISB will typically offer a configurable, reusable activity template for RSSto XML mapping.

Another common activity template will beselection-based routing. Dave’s application may emit a cancel car reservationID=1234 message. If one town car service’s reservation codes begin with “LE-“and another’s begin with “OL,” Dave’s application can send cancel events to asingle ISB URI. The selector then processes the message and routes to thecorrect endpoint.

Combining activities for more complexmessage processing is useful and will be a common function of ISBs. As anexample, Figure 6 shows the activities at the URL that Dave defines forreceiving the cancel car reservation message:

1.     Receives the cancel message in XML using WS-*.

2.     Has an activity that extracts the reservation IDelement and looks the prefix up in a table.

3.     Transforms the message to the expected format ofthe town car service, which is

·        a) HTML email for one provider

·        b) HTTP POST for the second provider.

Figure 6: ISB Message Processing (Click on the picture for alarger image)

Building message processing functions canbe quite simple. Many, many of the common application scenarios are simpleinstantiations of patterns and templates. An ISB provider will offer a simpleWeb-based application development tool that allows the developers to selectactivity templates and set the configuration parameters through a Web form. Inthe routing case, the Web form would allow the developer to specify the messagefield for routing and values in the routing table. Over time, ISBs will offermore powerful tools like the message processing tools in BizTalk.

Message processing (routing,transformation, and so on) is powerful enough for many application scenarios.Simple sequencing and flow of control is required for others, however. Considerthe task of booking a hotel in Dallas when Dave is stranded. A simpledescription of the process could be:

1.     Send a reservation request to hotel chain AAA

2.     Receive a response.

3.     If success then exit

4.     Send a reservation request to hotel chain BBB

5.     If success … …

Workflow activities extend messageprocessing with activity templates for flow of control like while, if ... then…, and so forth. ISBs will incrementally add support for simple workflow toextend the basic message processing.

Workflow can appear to be a complexconcept, and systematic enterprise workflow solutions are powerful and complex.The vast majority of workflows for ad hoc, opportunistic applications areextremely simple, however. The structure is not significantly more complex thansimple PowerPoint diagrams. There is a small set of “clip art” for connectionsand shapes, and the developer sets properties on the shapes to express thebehavior of the activity.

Most workflow processes tend to have thestructure of a nested list. This enables simple tools for building theworkflows. A simple XSD can provide the structure for XML documents defining anested list workflow. A visual tool allows the developer to specify the activitiesand their implements or connection to external services. A broad community ofdevelopers is familiar with this model because Web UI frameworks often providea similar concept for page flows and transitions (Struts, for example).

Systematic workflow solutions are oftencomplex because they are mission-critical and support applications thatthousands of people use. The process modeling and engine must be able toexpress the full functions of the process and handle complex error conditions,approvals, and so forth. In contrast, for most opportunistic, ad hoc solutions,a small group of people uses the workflow, and the team is constantly tinkeringwith it to improve it.

Service Level Objectives

Enterprises deploying applications on theISB will want to define Service Level Agreements (SLAs) specifying responsetime, throughput, availability, and so on. The SLA will determine the cost thatthe ISB provider charges. The general problem of achieving SLAs for arbitraryapplications is daunting. The ISB’s task is simpler, however, because it doesnot deploy arbitrary user code. Instantiating and configuring prebuilttemplates for policy, publish/subscribe, workflow activities, for example,constrains the applications. This simplifies achieving SLAs, predictable cost,and integrity.

A Reference Architecture for Software and Services forOpportunistic Applications

Figure 7 provides an extremely high-leveloverview of how the strands in this paper come together. First, the Internetservice bus is ubiquitous and connects all systems and servers. There will bemany composite applications in which some elements are on the “ESB” and othersare on the ISB. Multi-organization composite applications are one obviousexample that would deploy elements onto an ISB in the cloud. Anotherpossibility is single organization composite applications with a shortduration. For example, a composite application that an enterprise uses tomanage an internal conference. Reusing a preconfigured and installed “in thecloud” software platform may be more efficient than acquiring, installing,configuring, and supporting hardware and software to run the application “inhouse.”

Figure 7: An Ecosystem and Business Model (Click on the picture for alarger image)

If the enterprise reuses the ad hocapplication for several conferences, a systematic solution may emerge from theopportunistic solution. The opportunistic solution provides a concrete set ofuse cases for the systematic solution. It can also provide metrics fordetermining which aspects of the application are frequently used.

Third parties will connect value addedservices to the ISB. The first type of services will be infrastructureservices, such as a more powerful workflow engine or an XML Query enableddatabase. Developers can include these services in their solutions by connectingthem to URIs in their application. These infrastructure services are an exampleof how third parties can join the ecosystem by providing advancedinfrastructure as a service.

The second type of service will be reusablebusiness services—for example, a prebuilt service for maintaining productinformation and catalogs. Another example might be conference room schedulingfor conventions. This is an example of a third party joining the ecosystem byadding an application “building block” service. ISB composite application canuse the building block by connecting a URI in the composite application to thebuilding block service.

Finally, system integrators and solutionvendors will offer configurable, extensible solutions that are templates. Athird party may offer a configurable solution that supports many of theconference/convention management functions. A packaged application vendor canoffer the benefit of enabling “try and buy.” Instead of shipping a CD thatrequires installation of the application and prerequisites, a potentialcustomer can simply instantiate a version “in the cloud.”

Community is an important aspect of Web2.0. It may in fact be the most important aspect. Infrastructure services,basic application building blocks, and solution templates will also emergethrough a community associated with ISBs that offer and share code. Thecommunity also provides a forum for self-service support and establishing thereputations of “software as a service” providers.

Software + Services

Total “Software as a Service” is a myth.All meaningful SaaS solutions will eventually include some on-premise software– a hybrid. Some elements of an instantiated solution will reside in the bus(workflows, for example), some will reside in services connected to the bus (suchas an XML content management system), and some will “install” on premise.Almost all scenarios that use an ISB and SaaS are actually a hybrid of on premiseand off-premise software.

For another example, consider a datastorage provider that Dave uses to store the itineraries in his application.Always using remote access to read/update the itinerary is fragile. The storagevendor will likely provide an on-premise and on-PC software package thatoptimizes data access through caching, replication, versioning, and so on. Aterm for the hybrid model is software + services.

Conclusion

Several trends are coming together toradically transform the Web application model. Currently, the Web primaryenables connecting people to documents and applications. The fundamentaltransformation is thinking of the Internet and Web being the platform on whichapplications execute. Professionals with basic programming skills writepersonal applications that make their use of the Web far more efficient. Theywill share these applications with less computer literate friends andcolleagues. Communities will emerge that provide another approach to spreadinga personal solution “meme” through the community.

Inevitably, elements of the personalapplications will “move into the cloud.” A major source will be the broad useof “virtual” PCs that assemble themselves based on the user and nearby devices.Instead of using a notebook in a hotel room, the PC will assemble from thetraveler’s mobile phone and the TV, Internet connection and keyboard in theroom. It is possible to assemble a Virtual Machine (VM) that includes just thesoftware needed to implement a specific scenario.

The VM also provides:

·        Application isolation

·        End-user administration by implementing aconceptual model similar to how the user manages personal computers

·        Natural exploitation of scale-out processorsbased on multi-core.

The benefits to enterprise of theconvergence of these trends include:

·        Significant improvement in employee productivityand morale. Work is less tedious, more focused on business value tasks andpotentially fun.

·        Increased agility and responsiveness becauseapplication development and modification can occur in hours instead of months.

A key enabling technology for thesetransformations will be an Internet service bus. SOA, Web services, and mashupsenable rapid development of composite applications that integrate, customizeand extend base application building blocks. Enabling these composites in theWeb is the next major leap and a core aspect of Web 2.0. The critical elementin achieving the promise is an Internet service bus. In addition to enablingflexible application development, an ISB enables an ecosystem of softwareproviders. The capabilities of the ISB support the emerging populate of “programmingliterate” professionals entering the workforce, especially for bottom-upcommunity development of long tail applications. The unifying theory of thecomputing universe is software and services, and the ISB is the keystone ofthis new application model.

Resources

·        Biztalk Adapter http://msdn2.microsoft.com/EN-US/library/aa744368.aspx

·        Biztalk Labs http://labs.biztalk.net

·        Enterprise ApplicationIntegration (EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration

·        Enterprise Service Bus http://en.wikipedia.org/wiki/Enterprise_service_bus

·        Mashup http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

·        Model View Controller http://en.wikipedia.org/wiki/Model_view_controller

·        OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/

·        SAP RFC http://en.wikipedia.org/wiki/ABAP

·        Straight Through Processing http://en.wikipedia.org/wiki/Straight_Through_Processing

·        Struts http://struts.apache.org/

·        Use Cases http://en.wikipedia.org/wiki/Use_cases

·        WS-Eventing http://www.w3.org/Submission/WS-Eventing/

·        WS-Security Security Token Service http://sts.labs.live.com/

·        Zorro’s ISB Blog http://zorroisb.spaces.live.com

About the Authors

Dr. Donald Ferguson is a Microsoft TechnicalFellow in Platforms and Strategy in the Office of the CTO. Don focuses on boththe evolutionary and revolutionary role of information technology in business.Prior to joining Microsoft, Don was an IBM Fellow and Chief Architect for IBM’sSoftware Group (SWG) and chaired the SWG Architecture Board, which focused onproduct integration, crossproduct initiatives and emerging technology,including Web services, patterns, Web 2.0 and business-driven development.Don’s primary hobby is Kenpo Karate. He earned his black belt in December 2005.

Dennis Pilarinos is a senior technical leadin the Connected Systems Division at Microsoft. You can learn more about hiswork from his blog at www.dennispi.com.

John Shewchuk drives the TechnologyStrategy team for Microsoft’s Connected Systems Division (CSD). In CSD, Johnhas worked to develop Microsoft’s application platform, including work onapplication messaging technologies like the Windows Communication Foundation,Web services interoperability specifications such as WS-Security, and identityand access technologies such as InfoCard. John co-founded the Indigo team andhas been a key driver in cross-industry interoperability. With others on theIndigo team, John led development of the Web services architecture andspecifications and managed technical negotiations with a broad range ofindustry partners.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the Architecture Journal Web site.