A fluffy draft on a fluffy topic - feedback and flames encouraged...
While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service-oriented efforts have been successful. SOA projects may experience limited success when they are driven from the bottom up by developers unfamiliar with the strategic needs of the organization. Building SOA for the sake of SOA without reference to the business context is a project without organizing principles and guidance. The result is a chaotic implementation that has no business relevance. On the other hand, taking a top-down enterprise-wide approach to SOA requires such enormous time investments that by the time the project is complete, the solution no longer maps to business needs. (This of course is one of the problems SOA is supposed to solve!)
By contrast, Microsoft advocates a “middle out” approach which combines both top-down and bottom-up methodologies. In this approach, SOA efforts are driven by strategic vision and business need, and are met through incremental, iterative SOA projects that are designed to deliver on business goals one business need at a time. Microsoft has been using this technique to assist customers with their SOA initiatives since the .NET framework was first released in 1999.
The concept of SOA can be viewed from several possible perspectives. While no single perspective or set of perspectives represents a definitive view of a SOA, from a holistic view these perspectives assist in understanding the underlying architectural requirements. Microsoft believes that there are three abstract capability layers exposed within a SOA:
An illustration of these categories and their relationships to one another appears below:
Figure 6: An Abstract Reference Model for SOA
Expose focuses on how existing IT investments are exposed as a set of broad, standards-based services, enabling these investments to be available to a broader set of consumers. Existing investments are likely to be based upon a set of heterogeneous platforms and vendors. If these applications are unable to natively support Web services a set of application or protocol-specific set of adapters may be required. Service creation can be fine grained (a single service that maps on to a single business process), or coarse grained (multiple services come together to perform a related set of business functions). Expose is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though use of an adapter. A Service Implementation Architecture describes how services are developed, deployed and managed (we will cover this topic in greater detail in Chapter 2).
We will examine the Expose concept in greater detail in Chapter 2 (Service Orientation).
Once services are created, they can be combined into more complex services, applications or cross-functional business processes. Because services are exist independently of one another they can be combined (or “composed”) and reused with maximum flexibility. As business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications. Services compositions enable new cross-functional processes to emerge, allowing the enterprise to adopt new business processes, tune processes for greater efficiency, or improve service levels for customers and partners. A Service Integration Architecture describes a set of capabilities for composing services and other components into larger constructs such as business processes.
Composing services requires some sort of workflow or orchestration mechanism. Microsoft provides these capabilities via BizTalk Server 2006 (BTS) or Windows Workflow Foundation (WF). While BTS and WF may appear to serve similar needs, they are actually quite different. WF and BTS are complementary technologies designed to serve two very different needs:
We will examine workflow, orchestration and the use of BizTalk/WF in Chapter 3 (Workflow and Business Processes).
When a new application or business process has been created that functionality must be made available for access (consumption) by IT systems, other services or by end-users. Consumption focuses on delivering new applications that enable increased productivity and enhanced insight into business performance. Users may consume “composed” services through a broad number of outlets including web portals, rich clients, Office business applications (OBA), and mobile devices. “Composed” services can be used to rapidly roll out applications that result in new business capabilities or improved productivity. These application roll-outs can be used to measure the return on investment (ROI) in an SOA. A Service Oriented Application Architecture describes how “composed services” are made available for consumption through as business processes, new services or new end-user applications. This concept is sometimes referred to as Composite Applications since it implies service consumption by end-user applications. Microsoft’s Office Business Applications (OBAs) support the Composite Application notion of transactional systems while expanding the scope of user interaction via the familiar Office environment.
We will examine consumption in greater detail in Chapter 5 (User Experiences).
While the architectures described within Expose / Compose / Consume may be interdependent, they are designed to be loosely coupled. This enables services to be managed, versioned and configured independently of how they are exposed,
A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed
My friend John Evdemon has been writing about the different components of a SOA Reference model. Check
Being an intro, I expected this to be short of details. I think, however, a few topics should at least be mentioned (if not introduced) in the beginning.
First, I saw several places in your post reference "web services." I assume this corresponds directly with SOAP over HTTP/HTTPS. Does this mean you would exclude SOAP over MSMQ (or any other protocol) as a SOA communication mechanism? Clarification of this would be good.
I think the following paragraph could probably make a decent book when explained:
"While the architectures described within Expose / Compose / Consume may be interdependent, they are designed to be loosely coupled. This enables services to be managed, versioned and configured independently of how they are exposed"
Versioning, location independence, eventing, and scalability are a few of my core concerns at work right now in regards to our current Web Service architecture.
I also love to see you address the topic of passive vs active services. In terms of reuse, do you envision building many small services which can be composed into larger services? How do you deal with chattiness and semantic dissonance between services.
The topic of RPC vs Message integration is another huge concern (both are possible with Webservices, but most people do RPC without realizing the difference).
Would you define an enterprise data model for your services (the one customer format to rule them all)? If so, how do you deal with data stuffing when one application does not know all the fields of the enterprise data model.
Transactions are another huge topic. Do you forsee the use of cross-service transactions in this reference model? How will you deal with high-traffic applications and the locking issues that will entail?
Will your reference model allow for any type of eventing model?
Finally, how do you test and monitor the ecosystem to ensure the business SLA's are met (and issues are identified quickly).
I don't expect you to address many of these items in your "introduction," but maybe a few key points would be helpful to see what direction you are taking your SOA reference model (at which point I could give more directed questions/feedback).
Your first paragraph is full of assertions that are dubious. SOA, IMO, is not about responsiveness but about extending the object-oriented paradigm to include enterprise policy and business rule capabilities. And SOA initiatives are in such infant states that to pronounce that any have failed misses the scope and dedication that will be required to see a true project through.
I'm guessing that a few misguided and misunderstood attempts at building SOA prototypes have failed,that much may be true.
By introducing top-down and bottom-up development contentions, again you miss the point because you miss the scope. SOA is about enterprise wide service capabilities. That means multiple lines of business are affected. SOA cannot be driven by a single line of business unless that business is the enterprise itself.
Therefore, top-down and bottom-up strategies except in the case cited are doomed to misrepresent whatever their final by-product comes out to be. The mission accomplished will turn out to be SOA-coated business as usual. This is already happening in the financial services industry. Old habits are hard to break.
The monumental challenge of SOA is to disengage industries who have been politically married to exclusive vendors by last generation's bureaucracy to realize the ability to decouple from those staggering legacy dependencies. In other words, the client developers need to ween themselves from needing to care where the data comes from.
SOA also means data is no longer repository dependent. Data exists in time in motion. Services deliver what's on the wire, not what's in a location.
SOA is about business context in motion as well. That's why businesses who think you just need BA's running around gathering opinions about GUI designs will fail.
Client targets will be chameleons to the business of the moment, the business on the wire. SOA empowers that, it doesn't conform to stagnant templates. And SOA empowers collaborate, spontaneous business. End-users can't be pumpkins, they have to know something.
Your arguments are otherwise interesting and I'll think about them.
If it is meant to be truly abstract, there should be no specific technologies or protocols, cardinalities or specializations of components. From the graphic above, this effort fails dismally on all counts.
Data, legacy, packaged app, etc. are all specializations of somethings. In the OASIS SOA RM, this was referred to as capabilities. An abstract architectural artifact should not be specializing one artifact in many ways.
Is security something that is really there in SOA? The concept is really a policy. A policy can be a security policy but the security policy can also be that there is no security.
Sorry - but this fails the litmus test for me. Why not just use http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
as the basis for this work and make changes where you think there need to be changes. The OASIS work was never intended to the "the" (ie - singular) RM for SOA, just "one" RM. You may easily use it to point out differences where your SOA disagrees with the RM. That is the purpose.
Some practical considerations that should be addressed:
- Stand against fine grained v/s coarse grained services?
- Handling of services dependencies?
- Handling of reference data across autonomous services (eg. customer's industry in relation to a customer entity)?
- Handling of data integrity across autonomous services (eg. customer reference in say Order Proccess Service)?
- SOA with (or in the face of) ADO-ERD,DLINQ, LINQ??
- EDA (Event Driven Architecture) with SOA?
- Loosely Coupled Integration of Services? Consideration for Enterprise Service Bus (ESB) therein?
- Exposing of Database as Services, and applicability of CRUDy Services (See MS CRM 3.0 Web Service)?
When can we expect the final document? And lastly, perhaps you should consider following it up a real-world code sample - walk the talk?
Look - an RM has been done. What would really be helpful is a reference architecture to map the RM to WS-*. Rishi's comments above are very relevant to a lot of people. Making another abstract model is not going to help much. Making a reference architecture that maps the RM to WS-* will be very useful.
The RA team is meeting in San Diego this week to work on a first draft of an RA based on the last 9 months of their work on their Wiki. It would be great to get great minds like John's behind this work (or helping steer it).
This is a great topic to get addressed but as such your fluffy draft does not have much content:
- Building systems (no matter SOA based or not) requires addressing strategic needs of the organization involved. This is really nothing new. We know this for eternity. Corollary: What Microsoft advocates as per your introduction is nothing new. You can use Microsoft tools and technologies (or for that matter any other stack) to build great or clumsy systems depending upon taking a good or bad approach.
- I would be too careful to say that the graphics of Fig. 6 represents any kind of reference model.
- What you have described apropos of Expose, Compose, and Consume are not architectures at all as you have claimed. Just asserting something being an architecture normally does not render it so.
- You might not have wanted to sound it so but it feels that you want to run Expose, Compose, and Consume in a serial fashion which contradicts to your basic thesis that SOA projects should be driven by strategic business needs.
I am sure you shall come up with a great paper finally.
Microsoft Abstract SOA Reference Model and SOI codenamed Alchemy
A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service-oriented efforts have been successful