Posts Tagged ‘SOA’

If you’ve been getting involved in any enterprise SOA initatives, you may have come across the term “service virtualization”.  Novice SOA practioners and architects just getting into the SOA mindset are sometimes confused as to what exactly this means.  I think it is best explained by a metaphor to a real-world “virtual” service.


Perhaps the most popular “virtual” service is a stock broker.  Stocks are traded on several different exchanges throughout the world.  Stocks may be traded on NASDAQ, NYSE, London Stock Exchange, and many more around the world.  Each of these exchanges have their own rules governing fee’s, taxes, transactional flows, currency, trading times etc.


We, as consumers of these services, don’t want to concern ourselves with the specific implemenation rules of the different exchanges.  We leave this complexity of buying and selling rules to the virtual service – the stock broker.


In this example, specific exchanges provide concrete implemenations while the stock broker provides a virtual service.  Virtual services provide this level of abstraction and shielding from specific implementations for the end-point consumer.

Microsoft just announced its resources and tools investments in adopting SOA. Some of the tools in this set were obvious. As can be expected, the prototype project Biztalk Services will be available as a CTP very soon. I spoke about the huge potential of this project a while back and its nice to see it coming to light. Biztalk Services takes the concepts of an ESB, and pushes it into the internet cloud – an ISB (internet service bus) if you will.


“Oslo will enable a new class of applications that are connected and streamlined — from design through deployment — reducing complexity, aligning the enterprise and Internet, and simplifying interoperability and management.” – Robert Wahbe, Corporate Vice President of the Connected Systems Division

This vision will be delivered through several servers and tools:



  • Server:  Microsoft BizTalk Server “6″ will continue to provide a core foundation for distributed and highly scalable SOA and BPM solutions, and deliver the capability to develop, manage and deploy composite applications.

  • Services:  BizTalk Services “1″ will offer a commercially supported release of Web-based services enabling hosted composite applications that cross organizational boundaries. This release will include advanced messaging, identity and workflow capabilities.

  • Framework: The Microsoft .NET Framework “4″ release will further enable model-driven development with Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF).

  • Tools: New technology planned for Visual Studio “10″ will make significant strides in end-to-end application life-cycle management through new tools for model-driven design of distributed applications.

  • Repository: There will also be investments in aligning the metadata repositories across the Server and Tools product sets. Microsoft System Center “5,” Visual Studio “10″ and BizTalk Server “6″ will utilize a repository technology for managing, versioning and deploying models.

I think October 30, 2007 will be known as the day Microsoft went SOA.  This might be my favorite release (this hour) confirming Microsoft’s commitment to SOA.



 ”The Managed Services Engine (MSE) is one approach to facilitating Enterprise SOA through service virtualization. Built upon the Windows Communication Foundation (WCF) and the Microsoft Server Platform, the MSE was developed by Microsoft Services as we helped customers address the challenges of SOA in the enterprise.

The MSE fully enables service virtualization through a Service Repository, which helps organizations deploy services faster, coordinate change management, and maximize the reuse of various service elements. In doing so, the MSE provides the ability to support versioning, abstraction, management, routing, and runtime policy enforcement for Services.”


 

I was reading an old post by Simon Guest about removing the intimacy to create services and thought he had a great analogy comparing real life to SOA solutions.  I love these types of posts because they provide concrete examples which explain system interactions in a straightforward manner.  Gregor Hohpe posted something similar to this in Starbucks Does Not Use Two-Phase Commit post.  It’s a great read. 

I would like to take Simon’s post a few steps further.  Continuing on his example, let’s add a few more features such as:


1.  Message Correlation
2.  Message Expiration
3.  Concurrent Orchestration
4.  Policy-based security

When person A approaches person B to borrow $5, B must first make sure that he (1) knows who A is and (2) can trust A with this transaction.  Even though A looks like who he says he is, and he even knows B’s name and address, B has a strict “policy” that A must provide a state-issued ID (federated security) which B scans into his security manager to verify A’s identity. 

After his identity has been verified, B looks up A’s record and current outstanding balance.  B will check if his business rule stating that no one person can have an outstanding balance of more than $100 has been violated (business rules engine).  A promises to return B’s money in 7 days and that’s fine with B’s business rule. 

In B’s orchestration engine (his brain), he creates a new long running transaction where he listens, waiting for A to return his money, on or before today + 7 days.  He creates an alert in his process manager (his Blackberry) to send himself and person A an alert if he has not received the “money returned” message by that day.  If no message comes in by this time, a new process will be instantiated to mitigate the situation (the sendTonyToBreakLegs process) which receives a violatingEntityIdentifier message as its input message.

B is a very generous guy and let’s a lot of people borrow money.  He may have several long running transactions going on at any given time. In fact, person A could be going through some hard times and may have borrowed money several days in a row.  Each transaction is assigned a unique value so that when A starts paying back, he can start applying it the one closest to expiring.

When you look at daily life, it’s really one big integration project.  Orchestration, coordination, services, long-running transactions and asynchronous operations are all around us.  How well individuals deal with it is largely dependent on individual’s internal processing engines as well as accessibility to tools that specialize in the management of these processes (Blackberry, Outlook etc).


I’ve been involved in recent discussions on the divide between architecture
and technology.  I think many developers often confuse an
implementation technology with architecture.  I believe there is an
important distinction between the two.  This is often exemplified in
some people’s definition of SOA as “web services”. 
Apparently, if you can code a web service, you are officially a service
oriented architecture guru.  I was reading an e-book I found on MSDN’s
Architecture site and thought it provided a good metaphor depicting how
important it is to have an architecture blueprint and know the
difference between architecture vs. technology.  At the risk of
duplicated content on the web, here it is and the book can be
downloaded here:

“The
Winchester Mystery House is an intriguing tourist attraction in the USA
near San Jose, CA. The Winchester Mystery House was the home to the
heiress of the Winchester fortune (amassed from the sales of Winchester
rifles). According to the legend, the heiress went to see a fortune
teller and learned she was cursed to be haunted by the spirits of
everyone ever killed by a Winchester rifle. The only way to avoid the
curse was to build a mansion – as long as she kept building the spirits
would leave her alone. She promptly hired 147 builders (and 0
architects), all of whom began working on the mansion simultaneously.
The builders worked on the mansion until the heiress passed away, 38
years later. The result of their efforts is a classic example of
implementation without architecture:

  • The mansion contains 160 rooms, 40 bedrooms, 6 kitchens, 2 basements and 950 doors
  • Of
    there 950 doors, 65 of them open to blank walls, 13 staircases were
    built and abandoned and 24 skylights were installed into various
    floors.
  • No architectural blueprint for the mansion was ever created.

Confusing
architecture with implementation generates chaotic and unpredictable
results – much like the Winchester Mystery House. Articles that try to
explain SOA and jump into a tutorial for building Web Services are
providing guidance for coding, not architecture. This is one of the
many reasons that SOA is so misunderstood today – the rush to promote
loosely coupled architectures focuses on the trees instead of the
forest.