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, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: March 2005 X