Welcome to my Blog.
Spring is in the cool, Midwest morning air, (and despite the drizzle outside) birds are chirping away and I feel it's a good time to start things. I hope you will find the experiences I will be sharing with you informative or even interesting and worth your time.
Here, I will be sharing some observations, experiences and conclusions about SOA; on how/what things worked on projects (and were needed to succeed) in the modeling, analysis, design, development and management of service-oriented architecture.
I will share what things (e.g., practices, methods, etc.) helped the project succeed. After using them successflly a few times I like to think of these practices as "leading" practices. And then, maybe, after a while, when they work in several domains, we might call them "best-practices". But I'll also talk to you about "worst-practices" or "gotchas"; things that were counter-productive or that just don't work when you are building service-oriented architecture.
Everyone probably have their own definition of SOA; here's one that I like to use:
"An SOA is an architectural style that is reflected in an enterprise-scale IT architecture. It enables access to distributed resources, on demand.
An SOA consists of a set of business-aligned IT services that collectively fulfill an organizations business processes and goals. These services can be choreographed into composite applications and can be invoked through open protocols.
In an SOA, resources are made available to participants in a value-net ("eco-system") at various levels of granularity: enterprise, line of business or project levels.
The three fundamental constructs around an SOA are services, enterprise components that provide the functionality and quality of service for those services and flows or processes that string the services together. The primary structuring element, however is the 'service'."
So that begs the question, "what's a service?":
"A Service is a [discoverable] software resource which has an externalized service description. This service description is available for searching, binding and invocation by a service consumer. The service description implementation is realized through a service provider who delivers quality of service requirements for the service consumer. Services can be governed by declarative policies. "
There are a lot of definitions out there, and what I have described is just one of them. If you need more detail or clarification, let me know. Definitions are, however, just a good starting point and we have to move on from there pretty quickly and get the job done :-)
Some key ideas are: service-oriented architecture is an architectural style with some guiding principles about how to build more loosely -coupled, business aligned software that can adapt and be re-composed or re-configured to quickly meet new business needs. As an industry, we are maturing in that direction.[Read More]
BPM & Service-oriented Architecture: Insights and Best Practices
Ali_Arsanjani 120000D8QB 799 Visits
I have been travelling every week for the past four weeks several locations per week... one theme seems to recur: the need to discuss what are the essential elements or constructs of an SOA, so we can go about building them.
In the world of OO, an Object has identity, state (attributes) and behavior (methods). In the world of SOA, a Service has a description which describes the interface to use to invoke its functionality. To be successful, services must also have a contract showing their quality of service (QoS) attributes. Thus, a Service Provider would guarantee a certain quality of service accompanying the functionality it is providing.
In order to build an SOA, which often implies both consuming and providing services, we need to identify three contructs: services, components and flows (processes). The services are realized through a special class of components, service components. Service Components not only provide the functionality for the services, but is a monitoried, managed enterprise-scale asset that is a governed, funded component. A Flow or process is used to choreograph/orchestrate services. Sometimes, a process is composed of a combination of services and hard-coded parts of the process; for performance or funding reasons, not every bit of functioanlity is separated out as a distinct service (e.g., a Web service).
Therefore, services have a service description that exposes their functional interface, but also has two additional elements reflecting the non-functional aspects of policies as well as the data model snippets they relate to, as depicted in their (input and output) messages. So services have a functional and operational side to them that are BOTH externalized so that they can be found, bound and invoked or applied (in the case of policy).
These three fundamental constructs must be identified, then specified in greater detail and then, finally, realized using some technology mapping. This process of service modeling is described in the Service-oriented Modeling and Architecture method.
The first glimpse at the relation between services, components and (flows) processes is depicted in this high level SOA Reference Architecture .
Ali_Arsanjani 120000D8QB 734 Visits
Ali_Arsanjani 120000D8QB 770 Visits
When hitching a ride in the journey to SOA, there are at least six approaches you can take. One is a top-down business driven approach where you or your client want to improve and support business processes with recomposable services that can be exposed within the organization across business lines or between partners in the Service Eco-System
The migration path to SOA will require a choice of the approach.
Of the six approaches to SOA, I briefly described the first one: top-down business driven. I am now thinking of how pilots are given various angles and approaches to airports based on traffic, wind, direction they are coming etc., which only shows that I need to get a life and travel less... but that's beside the point.
The others include: bottom-up legacy integration/enablement, data access driven, message or event driven , model-driven architecture (tools to generate web services) and legacy transformation.
Legacy Integration and Transformation are fundamentally bottom-up approaches: you start with something concrete and find a way to leverage it. Sorta like mathematical induction: from the particular to the general. Now back down to the ground of reality....
Customers want to expose functionality. In the first case functionality that is isolated and can be wrapped and mapped to a mid-tier application server. In the second case, the bottom-up approach is still related to legacy, but in this case the functionality requires some software archeology: it's embedded into the bowels of the legacy system. Now you need some form of compiler-based technologies (many of which evolved from the Y2K days) to extract re-usable portions of code that can be accessed from anywhere, not necessary through the mechanisms of the legacy system.
The two top down approaches are business driven and model-driven: the first one is based on bsuiness processes and the need to align and improve them. The second is based on tools and their ability to generate useful code from a top-down rendition of the business model or analysis model.
Some companies want to start with improving their businesses by focusing on the processes. Others may have more IT focus where they want to improve the business by improving the way IT does the job of supporting the existing processes.
Then we have two approaches that come in sideways: data access and message/event driven. Some people could care less about SOA or any other latest cool technology or promising paradigm; they just want to have a single uniform and consistent way to provide interface-based access to their underlying data: check the status of an order, place an order, access customer data, etc.
And others, coming in from the other sideways angle only care about integration; without knowing or caring about the two points of integration. In otherwords, I want to connect two systems they say and SOA gives me a very clean way to do so. I care only about messages exchanged between systems and the events that trigger the exchange of data or the invocation of a service.
Ali_Arsanjani 120000D8QB 789 Visits
Granularity is a tricky topic that I get queried about very often. It's more than a single metric measurement; it's how useful the interface is to you the potential consumer and how you can re-compose it in your own application context.
But there are many consumers out there; at one end of the spectrum are low level API's such as those typically found in packaged applications that vendors expose as Web Services. Then we get the grand bundling of an entire application as a service at the other end of the spectrum.
But it's all about how IT fits the business goals. Allow me to digress. In karate, there is a notion of "maai". It is the distance you have to step back to avoid being punched when the attacker comes in for a punch and the distance you have to step forward in order to be able to strike. 'So, how long is a "maai"?' someone may ask. I don't know how many feet and yes, it depends on ....
Back to SOA. When we do goal-service modeling, the composition of services and their granularity is attached to the sub-goal in the goal tree that you create. Higher level goals requiring services will have larger granularity services.
Granularity is inspired by buisness usage context that maps to business goals fulfillment that translates into what services you need to fulfill a given goal.
Okay, now, we will practice that move one more time. Yoi...(ready)...[Read More]
Ali_Arsanjani 120000D8QB 1,101 Visits
One unique feature of SOA is that it is "fractal." The fractal nature of SOA implies that it is applicable in small projects, to one line of business, several lines of business sharing common services with slight variations, cross enterprise scope, between business partners in a value net and then on a larger scale in the service eco-system.
Ali_Arsanjani 120000D8QB 891 Visits
I have been talking about the notion of a service eco-system for some time now. This is a mutually beneficial digital/human enviornment where actors are businesses that can choose to link to a remote resource using Web services. They combine their efforts in a value-net of services; similar to a supply chain, but not just for suppliers and consumers; but for companies who choose to increase their competative edge by joing forces with business services porvided by other participants in the service eco-system.
You need an SOA method to identify services that SHOULD be exposed to your eco-system.
Also there are various layers in your SOA. We call them a SOA Reference Architecure . One of these layers is the data or information management layer. Check out this recent article on aspects of information management for SOA .[Read More]
The Service Eco-system needs standards-based externalization of function, policy, context and events
Ali_Arsanjani 120000D8QB 1,830 Visits
Well, over this weekend, deep in space, NASA has succeeded with Deep Impact and another impactor in the form of tennis balls were colliding: Federer has won his third Wimbledon in magnificent straight sets. As Roddick, his opponent, said,(paraphrase) "he is getting better than ever which is a surprise. I have been training hard and he is still getting better. maybe next time I'll punch him...."
The NASA mission showed our increasing precision through technology manipulated through software and (hardware)machines (many times context-aware services and components, but that is another story...) and the tennis champs showed they can progress with even greater precision on the human side.
Our precision in SOA and our success in winning with SOA depends not only on the initial standards and enabling technology, but on extending it to the enterprise scale and beyond into the ecosystem of partners.
To do this, we must focus on externalization of policy, of context and of sense and respond to events; whether the impact of a man-made satellite the size of a coffee table at 23,000 mph onto a raging bull of a comet, or Federer serving and acing at a precise 125 mph. These events, if signifcant to their corresponding businesses must be sensed and responded to. The response cannot be blind: a set of rules must be selected based on the context in which the event occurred and policies need to consulted in order to determine the valid/optimal course of action suitable for the business.
SOA seeks to externalize the interfaces to functionality, so a service consumer can find or use the URL/I and bind to the function without having to worry about the details of the underlying implementation; its design or technology. The service provider needs to also externalize policy information. Both provider and consumer need to monitor services and this is typically done via events. Events can serve as a service invocation mechanisms to wake up a service in a sense and respond scenario. And as the services are merrily firing on their own in blissful automation, the monitoring layering of an SOA should check for certian types of events that it is listening for based on business priority and policy.[Read More]
Ali_Arsanjani 120000D8QB 767 Visits
I have recently published an article here on dW regarding SOA and SOI patterns. Others have written in this space, most notably, Rachel Reinitz and Kyle Brown, and Bobby Wolf, three of my colleagues.
I focus on the ways in which we have done SOA with clients and discuss things that we see recurring, that seem to work well.
Ali_Arsanjani 120000D8QB 753 Visits
I have been a strong advocate of the notion of service eco-systems and have been sharing patterns that help accomplish this task through the design of SOA and SOI that is conductive to the creation and maintenance of a stable service eco-system.
Others have been talking aout various aspects of a service eco-system as well. For example, The role of contracts in the service ecosystem . Some talk about the Web Services Eco-system and how we need tools for consumpiton, test, creation and management.
Recently, George Galambos of IBM delivered a keynote on the Service Eco-system at the IEEE Int'l Conference on Web Services 2005.
Aside from wildlife foundations, Economists also have found interest in ecosystems. For example, they discuss the valuation of an ecosystem .
We'll be hearing much more about this important concept as technologies and organizations mature in their usage and adoption of SOA.
Ali_Arsanjani 120000D8QB 666 Visits
National tennis associations tend to be run by local groups within communities that observe certain rules in their tournaments and are therefore sanctioned by the national tennis association. No matter how small you are, you can run a tournament if you can solicit enough participation from members and show a well-organized venue.
This lowers the barrier of entry and provides smaller cities the opportunity to stage tournaments and encourage skill in sports near a person;s hometown.
This network of sports communities are observing a common policy defined by a larger organization and implemented locally.
Similarly, as your company matures in its adoption and usage of SOA, and turns from small projects to larger and more intricate uses of SOA as depicted by the Service Integration Maturity Model (SIMM) , the need to provide servies to business partners in a value net and to leverage services provided by other partners in the same value net presents a unique opportunity and a set of challanges.
The interactions between parties are no longer one offs but rather collaborative goal-oriented interaction in whcih a participant alternatively assumes the role of provider, consumer or broker and enacts business transactions that run across not one company but several companies transparently.
The leveraging of the capabilities of other companies within thi service eco-system enables greater value than static partnerships or of relying solely on ones own resources.
Furthermore, participants in the SOA Eco-system can be small or larger companies and the smaller ones can be shielded from unnecessary judgements so lang as they maintain SLA's and provide the advertised functionality. This is a network effect that the Internet saw in its inception, but of a new caliber for businesses to leverage one another transparent to their customers. Great empowerment.
Ali_Arsanjani 120000D8QB 945 Visits
A lot of times I am asked to describe and then implement an SOA as part of a client project.
One of the recurrent themes I have seen is that SOA can be described quite succinctly in terms of three dimensions:
functionality, policy and composition.
Functionality has to do with the fulfillment of requirements on the business side.
Policy has to do with the quality of service, non-functional aspects such as security, behavior in the face of changing levels of availability and duress that the SOA is put under.
Composition is in terms of how to combine the three key elements of SOA, namely, services, components and flows into more coarser-grained entities.
There is some excitement with this rich client-side engine that mediates data interchange rather unobtrusively in a browser frame, catching input and sending it to the server, catching the results and more gracefully rendering the results. This is a step up from the staccato jerks of normal HTML page interaction, providing a smoother transition between almost unobtrusive loads.
Google's Maps or Google Suggest (see how the search narrows as you type) are examples of using this technology. You program this with things like ECMA Script .
Ajax is a composition of standards and technologies that includes:
* data interchange using (surprise!) XML
* data manipulation with good old XSLT
* asynchronous data retrieval using XMLHttpRequest
* standards-based presentation (XHTML and CSS)
* dynamic rendering and interaction using a tree structure similar to a Document Object Model
Adding this layer of mediation to the presentation layer of your SOA will further enable Web services consumption:
Ali_Arsanjani 120000D8QB 1,390 Visits
Summer vacation is over for most families with children. School has either started or is imminently going to... vacations are therefore usually over and we are back into the swing of things. We were talking about building the layers of an SOA, based on an SOA reference model. Let's discuss how to build the service component layer which is responsible for realizing the functionality and quality (adherence to non-functional requirements) of the service.
OK. So we assume know how to model and design an SOA. For that, we use some sort of Service-oriented Modeling method such as SOMA.
You have gone through Identification, Specification and Realization of Services, Service Components and Flows (processes).
During Realization you need to build the SOA. You need to map each service, service component and flow to a realization decision.
Once you have this table, you then have an idea of what you will:
3. Integrate (wrap, adapt)
4. Subscribe to (if event driven or publish and subscribe)
5. Transform (break apart a legacy system to get access to hitherto hidden nuggest of functionality not exposed in the orginal application)
Let's take number 1. Build. Building something is often about using a programming model to construct that piece of software.
In the 6th installation of the SOA Programming Model, Ferguson, Stockton and Nally talk about "A language-neutral, component-based programming model for service-oriented architecture (SOA) facilitates the implementation of Web services and their assembly into solutions."
This describes how to build the service components that will implement or realize your services.
The previous set of articles in that series can be found here.