SOA is a big business buzzword tossed into conversations at board meetings and at executive briefings. At this level, however, SOA really refers to connecting disparate systems across application, department, corporate, and even industry boundaries. This is the “Big” SOA concept, and this is the realm of the enterprise architect.
This is the space of multimillion rand Service Bus applications, SAP systems and other wonderful products. But the fact still remains that a chain is a strong as its weakest link, if the systems hooked up to the top of the range Service Bus are not rock solid and can not be trusted to produce the correct results all the time, then the some of the true potential of the investment is lost.
The path to “Big” SOA begins with a solid base and the ideas presented in this paper will provide you with the tools you need to achieve this.
As businesses struggle to reap the rewards of their investment in a SOA approach, the importance of “Little” SOA is becoming lost in the marketing hype and scramble by vendors to sell you their version of service orientation.
This paper offers practical advice for building Service Orientated Applications, using service oriented programming (SO) as an approach, that shows that every component can be a service while still maintaining the technical requirements that modern applications are required to exhibit and in most cases surpassing what many application frameworks offer to date.
By building a solid “Little” SOA base, the platform is set at an enterprise level to realise the composition and reuse that is the value proposition of SOA, as without a “Little” SOA that is properly portioned, rock solid and composeable, attempts to realise more will fail.
I hope to share some of the best practices, techniques and tools that I have learned from the last two years of applying WCF to the construction of service orientated applications and also to provide an insight to application architects on how to achieve the non functional specifications that many projects only play lip service to.
The paper can be found at:
http://www.box.net/shared/3oce5tvf8f
Showing posts with label wcf. Show all posts
Showing posts with label wcf. Show all posts
Monday, July 13, 2009
Thursday, September 11, 2008
Design Principles
I am currently involved in the design phase of a project for a client, and have been thinking a lot about design principles, the sort of things that apply to all technologies and projects equally.
Readers of the blog will know that I have strong ideas on design and architectural form, but I felt a sense of validation when I came across a set of design principles that Amazon uses in the formulation of their elastic cloud technology stack.
The principles here map almost one to one to those which I hold and apply daily to my projects and architectures, these include:
Symmetry I perhaps use a bit differently, I apply it to the design of components, where by one component although different in function follows the same structure and layout of the others, so every bit of the system is symmetric to the others with regards to standards and layout.
Follow these, and good things will follow I promise!
I believe that process and architecture are different aspects of the same thing, so by aligning these principles with an architecture and process that support them you are putting blocks into place that will lead to success.
Readers of the blog will know that I have strong ideas on design and architectural form, but I felt a sense of validation when I came across a set of design principles that Amazon uses in the formulation of their elastic cloud technology stack.
The principles here map almost one to one to those which I hold and apply daily to my projects and architectures, these include:
- Decentralization: Use fully decentralized techniques to remove scaling bottlenecks and single points of failure.
- Asynchrony: The system makes progress under all circumstances.
- Autonomy: The system is designed such that individual components can make decisions based on local information.
- Local responsibility: Each individual component is responsible for achieving its consistency; this is never the burden of its peers.
- Controlled concurrency: Operations are designed such that no or limited concurrency control is required.
- Failure tolerant: The system considers the failure of components to be a normal mode of operation, and continues operation with no or minimal interruption.
- Controlled parallelism: Abstractions used in the system are of such granularity that parallelism can be used to improve performance and robustness of recovery or the introduction of new nodes.
Decompose into small well-understood building blocks: Do not try to provide a single service that does everything for everyone, but instead build small components that can be used as building blocks for other services. - Symmetry: Nodes in the system are identical in terms of functionality, and require no or minimal node-specific configuration to function.
- Simplicity: The system should be made as simple as possible (but no simpler).
Symmetry I perhaps use a bit differently, I apply it to the design of components, where by one component although different in function follows the same structure and layout of the others, so every bit of the system is symmetric to the others with regards to standards and layout.
Follow these, and good things will follow I promise!
I believe that process and architecture are different aspects of the same thing, so by aligning these principles with an architecture and process that support them you are putting blocks into place that will lead to success.
Monday, July 28, 2008
SOA and Anemic Domains
After a conversation with a work college of mine I was amazed to find that many people have not made the mind shift into a SOA way of thinking.
Most are in the 80’s with a pure OO paradigm; it’s a brave new world people, OO and its promise of reuse failed, no one ever reused pure business objects as is, ever.
The unit of reuse has moved from sharing code to delegation of functionality, the artifact of reuse has shifted from the object to the service. Don’t talk about sending objects around, rather keep the objects where they belong and send messages asking a service to perform actions on them.
They shout out, “but you have an Anemic Domain, it’s an anti pattern so you must be wrong”.
Are they suggesting distributed systems that pass around "real" objects, behaviour and all? You should cry out in terror at the thought of using such a system in production.
For an OO purist the domain model is the most important part, but for the enterprise the database is far more important, seen by the fact that many databases far outlive the applications built to access them.
In SOA land your OO business logic is not the only business logic involved here, your services are part of a large interacting web of autonomous services, some wrapping legacy systems, is their business logic any less important.
I say design your services right, services that are self contained, process/capability driven, have de-centralised data and which communicate via well defined messages will lead to deliverable architectures, nobody will care how elegant your business layer is if you never get it done on time.
Most are in the 80’s with a pure OO paradigm; it’s a brave new world people, OO and its promise of reuse failed, no one ever reused pure business objects as is, ever.
The unit of reuse has moved from sharing code to delegation of functionality, the artifact of reuse has shifted from the object to the service. Don’t talk about sending objects around, rather keep the objects where they belong and send messages asking a service to perform actions on them.
They shout out, “but you have an Anemic Domain, it’s an anti pattern so you must be wrong”.
Are they suggesting distributed systems that pass around "real" objects, behaviour and all? You should cry out in terror at the thought of using such a system in production.
For an OO purist the domain model is the most important part, but for the enterprise the database is far more important, seen by the fact that many databases far outlive the applications built to access them.
In SOA land your OO business logic is not the only business logic involved here, your services are part of a large interacting web of autonomous services, some wrapping legacy systems, is their business logic any less important.
I say design your services right, services that are self contained, process/capability driven, have de-centralised data and which communicate via well defined messages will lead to deliverable architectures, nobody will care how elegant your business layer is if you never get it done on time.
Friday, June 27, 2008
Non Functional requirements driving technology choice
With the slue of new technologies out of Microsoft over the past 2 years,
WCF, WWF, WPF, Silverlight, LINQ, Entity Framework, ADO.NET Data Services, MVC Framework, ASP AJAX etc... It is becoming increasingly confusing for developers to figure out what technologies to use, and how and where to apply them.
The danger facing many new projects is to fall into the trap of using a technology because it is new, rather than a good fit to the requirements of the problem at hand.
I always start with the non functional requirements before making any decision about the implementation technology.
Application architecture results from the balancing of functional and the non-functional requirements applicable to the system. Non-functional requirements (restrictions and constraints) serve the purpose of limiting the number of potential solutions that will satisfy a set of functional requirements.
Functional requirements are the behaviour that the owner of the system would like to emerge from the development process. All architectures exhibit emergent behaviour. If the emergent behaviours are not specified / managed in the form of non-functional requirements, the developers will choose them on behalf of business, leading to misalignment.
Architecture is applied at two levels:
·The application architecture addresses the software components of the actual application.
·The systems architecture addresses the physical (hardware) and logical distribution of components across the network environment.
The non-functional aspects that I usually consider when formulating architecture
Simplicity - number one non functional
Security – this requirement in my opinion is not an option, the five pillars of Authentication, Authorisation, Integrity, Confidentiality, and Non-repudiation need to be catered for in any application you design.
Performance – here I am looking at things like number of online transactions, batch runs and if applicable the throughput from a users perspective. The last one is quite important as to a user of any system with a front end, this is all that matters, this requirement often allows you to factor the system to cater for the different expectations that will be imposed in the system by its users.
Maintainability - The ease with which code can be understood and changed, the aspect of maintainability should be pervasive throughout any architecture you design, any item must be created with the eye towards maintaining it.
Integrity - Ability to detect and manage invalid data coming in to system and the imposition of complete transactions or rollbacks.
Extensibility - Ease with which new features can be added to the code, not the same as maintainability, things like composite applications work really well here.
Flexibility - Ease with which the software can be deployed in different environments.
Scalability - Ability of the system to grow with the organisation without code changes, increase in number of users, increase in number of transactions.
As you would have noticed, many of these requirements are in direct opposition of each other; in conjunction to this there is a price to pay for achieving any of them fully.
As a software architect the responsibility is on you to attempt to balance these conflicting forces and find the best alignment to fit the system specifications.
It is also your task to align technology risks with the appetite for risk of the organisation.
By evaluating the system against these non functional requirements first I find that my options of implementation technology usually get reduced into a manageable set.
WCF, WWF, WPF, Silverlight, LINQ, Entity Framework, ADO.NET Data Services, MVC Framework, ASP AJAX etc... It is becoming increasingly confusing for developers to figure out what technologies to use, and how and where to apply them.
The danger facing many new projects is to fall into the trap of using a technology because it is new, rather than a good fit to the requirements of the problem at hand.
I always start with the non functional requirements before making any decision about the implementation technology.
Application architecture results from the balancing of functional and the non-functional requirements applicable to the system. Non-functional requirements (restrictions and constraints) serve the purpose of limiting the number of potential solutions that will satisfy a set of functional requirements.
Functional requirements are the behaviour that the owner of the system would like to emerge from the development process. All architectures exhibit emergent behaviour. If the emergent behaviours are not specified / managed in the form of non-functional requirements, the developers will choose them on behalf of business, leading to misalignment.
Architecture is applied at two levels:
·The application architecture addresses the software components of the actual application.
·The systems architecture addresses the physical (hardware) and logical distribution of components across the network environment.
The non-functional aspects that I usually consider when formulating architecture
Simplicity - number one non functional
Security – this requirement in my opinion is not an option, the five pillars of Authentication, Authorisation, Integrity, Confidentiality, and Non-repudiation need to be catered for in any application you design.
Performance – here I am looking at things like number of online transactions, batch runs and if applicable the throughput from a users perspective. The last one is quite important as to a user of any system with a front end, this is all that matters, this requirement often allows you to factor the system to cater for the different expectations that will be imposed in the system by its users.
Maintainability - The ease with which code can be understood and changed, the aspect of maintainability should be pervasive throughout any architecture you design, any item must be created with the eye towards maintaining it.
Integrity - Ability to detect and manage invalid data coming in to system and the imposition of complete transactions or rollbacks.
Extensibility - Ease with which new features can be added to the code, not the same as maintainability, things like composite applications work really well here.
Flexibility - Ease with which the software can be deployed in different environments.
Scalability - Ability of the system to grow with the organisation without code changes, increase in number of users, increase in number of transactions.
As you would have noticed, many of these requirements are in direct opposition of each other; in conjunction to this there is a price to pay for achieving any of them fully.
As a software architect the responsibility is on you to attempt to balance these conflicting forces and find the best alignment to fit the system specifications.
It is also your task to align technology risks with the appetite for risk of the organisation.
By evaluating the system against these non functional requirements first I find that my options of implementation technology usually get reduced into a manageable set.
Subscribe to:
Posts (Atom)
