After having hosted a Cloud Computing event in November and hearing how companies are dipping their feet in the cloud, the next logical step we discussed was inter cloud communication. As a small company I may buy into Salesforce.com for CRM, Workday for HR/Financials and Google AppEngine for custom apps. How do I tie these solutions together for data synchronization? What if the data to be exchanged is extremely large? What solutions can I use to do the heavy lifting?
Service Bus solutions either deployed locally or in the cloud provide a composition medium to support such interactions. Cloud platforms expose public APIs via REST or SOAP for near-real time communication.
Large data sets and exchange of this for processing is being investigated by a interesting consortium called Open Cloud Consortium.
Another interesting area may be the creation of middleware in the cloud. Grand Central tried to support this in the early 2000 timeframe. It was a little ahead of its time but now we are seeing Amazon SQS, Microsoft Azure w/Biztalk and other similar platforms.
Thursday, December 3, 2009
QCon, Security and Musings
I was fortunate to speak at QCon San Francisco, CA on November 20 discussing Service Security and my own journey on understanding security but more importantly how services can be hacked. It was interesting when examining the audience to see a mixture of participants but the lack of questions was a little disconcerning. I could take three things from that:
1) Everyone in the audience was familiar with service hacking / security.
2) People are not very familiar and were afraid to ask questions or didn't understand the content.
3) People were not interested.
Since the audience stayed for the entire presentation and questions were basic, I think the majority of the audience was in category 2.
With the increasing discussion on Cloud Computing (QCON was loaded with Cloud presentations as was SOA / Cloud Symposium 2.0/1.0) security had very little presence. In understanding security, my own education was due to a client requirement. With just a couple months of effort, I was able to better understand the security technology. The harder part has been in understanding the hacking culture, finding helpful material and approaches and how that impacts services I create. Here is the link to the QCon presentation.
1) Everyone in the audience was familiar with service hacking / security.
2) People are not very familiar and were afraid to ask questions or didn't understand the content.
3) People were not interested.
Since the audience stayed for the entire presentation and questions were basic, I think the majority of the audience was in category 2.
With the increasing discussion on Cloud Computing (QCON was loaded with Cloud presentations as was SOA / Cloud Symposium 2.0/1.0) security had very little presence. In understanding security, my own education was due to a client requirement. With just a couple months of effort, I was able to better understand the security technology. The harder part has been in understanding the hacking culture, finding helpful material and approaches and how that impacts services I create. Here is the link to the QCon presentation.
Thursday, November 5, 2009
ECAUG 1.0: Architecture User Group
Wednesday this week I hosted a user group in Waltham, MA focusing on Cloud Computing experiences. I was fortunate to have Steve Robbins of Modus21 and Matson Wade representing HKM at the event. In their discussions, they broke down their experiences with Amazon Web Services specifically EC2, S3, SQS and a few other features. If you are interested in participating in the future, let us know. We can extend an invite to the Ning forum that we have setup and you can check out the presentations. A couple of criteria at the moment are you are based in the US and you are willing to proactively participate. No vendors are allowed which in turn provides a more frank and interesting discussion.
Thursday, October 29, 2009
SMB not fit for SOA?
During a training class I was leading today, a very interesting question came up which is "All this SOA stuff we have been talking about today is great for a large company but seems to be overkill for the SMB (Small / Medium Business). Since SMB makes up a much larger percentage of the business world then traditional business, why should we care?".
Well one way to look at the problem is that services are permeating the cloud computing space, in fact last week's SOA Symposium co-hosted a Cloud Computer Conference. Cloud computing is becoming a game-changer for SMB in providing a variety of tooling from productivity (documents, email, etc.) to CRM (i.e. Saleforce.com) to HR (i.e. Workday) to Infrastructure (i.e. Amazon/Azure). The one common aspect in these is the ability to interact using service APIs and thus the need for SMB to be adept at service consumption and composition.
Well one way to look at the problem is that services are permeating the cloud computing space, in fact last week's SOA Symposium co-hosted a Cloud Computer Conference. Cloud computing is becoming a game-changer for SMB in providing a variety of tooling from productivity (documents, email, etc.) to CRM (i.e. Saleforce.com) to HR (i.e. Workday) to Infrastructure (i.e. Amazon/Azure). The one common aspect in these is the ability to interact using service APIs and thus the need for SMB to be adept at service consumption and composition.
Wednesday, October 14, 2009
Versioning Podcasts
As part of my work with SOA Systems / SOABooks.com, I was asked to support Podcasts on versioning based on my participating with David Orchard (formerly BEA). Check the two podcasts out and fire over some questions if you have any.
Flexible Contracts?
After having delivered SOA Training to various clients this summer and fall many have asked how to deal with change. The contract is the center piece of services and with an effective versioning strategy it can be difficult to alter due to coupling that occurs with service consumers. David Orchard, James Pasley and others have been documenting versioning strategies. From my work with David on the SOA Patterns book(Erl 2008) and my consulting with organizations employing Agile Methodology, contract refactoring/change is a mandatory requirement.
Identifying a versioning strategy such as Strict, Flexible or Loose along with Versioning Identification and Compatibility design patterns provides a foundation for indicating change and providing consistency in managing the consumer impact.
For further details check out a presentation related to mixing Agile along with SOA Design Patterns and Meet in the Middle Strategy.
Identifying a versioning strategy such as Strict, Flexible or Loose along with Versioning Identification and Compatibility design patterns provides a foundation for indicating change and providing consistency in managing the consumer impact.
For further details check out a presentation related to mixing Agile along with SOA Design Patterns and Meet in the Middle Strategy.
SOA Symposium 2.0: Rotterdam, Netherlands
It is amazing another year has passed and SOA Symposium 2.0 is around the corner. As part of the presentation work, two areas that I have focused on in blog postings and customer work is in Agile Methodology and Service Hacking. Check out the presentations and feel free to post any questions.
East Coast Architecture Group: Cloud Computing Seminar
The past couple years has seen an increase in the discussion and interest in Cloud Computing. In my own experience it started with Salesforce.com in 2003/4 and then Workday which acquired Cape Clear in 2008. More recently I have been tracking the use of Amazon EC2/S3 etc. and the impacts that IaaS is doing to the IT community. To help customers and architects that I have interacted with in the past 10 years, my company is hosting / starting an Architecture User Group. The first topic to be discussed is Cloud Computing and people that have experiences with this medium. The following URL provides specifics on the topic and dates:
East Coast User Group: November 4th, 2009, Waltham, MA
East Coast User Group: November 4th, 2009, Waltham, MA
Saturday, July 11, 2009
Justification for constraining your XML Types
As part of work for a client and some training I need to perform in the future, I have been spending time on hacking of web services. A simple mechanism that is often unchecked is the use of types that have no restrictions within XML Schema and WSDL. An example is simple schema below where the Social Security Number is not restricted in length and type:
<xsd:element name="SSN" type="xsd:string"/>
If this element is used as a part of a SQL Query in a Web Services, there is the potential for SQL Injection attacks. SQL Injection is where hackers look for elements that are not constrained and thus can take advantage of the un-restricted size to insert additional sql. A simple mechanism to reduce this is to restrict the element via simpleType.
<xsd:element name="SSN" type="SSNType"/>
<simpleType name="SSNType">
<restriction base="string">
<minLength value="9"/>>
<maxLength value="11"/>
</restriction>
</simpleType>
This then reduces the overall buffer available for the hacker between 9 and 11 characters.
<xsd:element name="SSN" type="xsd:string"/>
If this element is used as a part of a SQL Query in a Web Services, there is the potential for SQL Injection attacks. SQL Injection is where hackers look for elements that are not constrained and thus can take advantage of the un-restricted size to insert additional sql. A simple mechanism to reduce this is to restrict the element via simpleType.
<xsd:element name="SSN" type="SSNType"/>
<simpleType name="SSNType">
<restriction base="string">
<minLength value="9"/>>
<maxLength value="11"/>
</restriction>
</simpleType>
This then reduces the overall buffer available for the hacker between 9 and 11 characters.
Thursday, May 21, 2009
Agile in the trenches (Part 1)
As part of my research on how Agile Methodologies can interface with Service-Oriented Architecture, I am working with a client performing a 2 week iteration. The iteration is focusing on automating a process via a Service Composition. The goal of the iteration is for an architect to provide a reference implementation for a development team. The development team will then use the reference implementation as the basis for the final service composition.
The reference implementation employs design patterns for version identification, process abstraction/centralization as well as design standards and industry standards. This implementation reduces the requirements on the development team to create the entire service composition and more on modification of a framework. The overall idea of having architecture teams support development teams came about in discussions with Kevin Davis. We discussed how the enterprise architecture team could become a much more effective participant in development cycles by performing co-development.
During execution of the architecture iteration the following was performed to keep the development team/architecture team interactions simple and concise:
1) Stand up meetings are replaced with email stand up meetings. The customer is the development team and to reduce the impact on this team, a simple summary of the current tasks and blocking issues are identified. The development team manager is responsible for getting blocking issues resolved.
2) An iteration planning meeting still occurs in this model to identify the user story(s) and development tasks. These are then entered into a Agile Management Tool for tracking and visibility.
3) A retrospection meeting occurs to demonstrate the user story solution and delivery results for the identified development tasks. As part of the delivery, a step by step documentation set is provided to help the development team utilize the reference framework.
This same process is being executed by other Architecture team members for future features/technology required by other development teams. The execution of these iterations is meant to help validate/alter the process towards a consistent delivery approach.
The reference implementation employs design patterns for version identification, process abstraction/centralization as well as design standards and industry standards. This implementation reduces the requirements on the development team to create the entire service composition and more on modification of a framework. The overall idea of having architecture teams support development teams came about in discussions with Kevin Davis. We discussed how the enterprise architecture team could become a much more effective participant in development cycles by performing co-development.
During execution of the architecture iteration the following was performed to keep the development team/architecture team interactions simple and concise:
1) Stand up meetings are replaced with email stand up meetings. The customer is the development team and to reduce the impact on this team, a simple summary of the current tasks and blocking issues are identified. The development team manager is responsible for getting blocking issues resolved.
2) An iteration planning meeting still occurs in this model to identify the user story(s) and development tasks. These are then entered into a Agile Management Tool for tracking and visibility.
3) A retrospection meeting occurs to demonstrate the user story solution and delivery results for the identified development tasks. As part of the delivery, a step by step documentation set is provided to help the development team utilize the reference framework.
This same process is being executed by other Architecture team members for future features/technology required by other development teams. The execution of these iterations is meant to help validate/alter the process towards a consistent delivery approach.
Tuesday, April 7, 2009
SOA in the DOD / Government
I just had the opportunity to participate at the latest SOA Symposium focusing on the Department of Defense and other government agencies. The theme was on the people aspects of SOA and how success is directly measured by the amount of collaboration and teamwork in the project.
Vendor presentations by IBM, Microsoft, Oracle, Red Hat and Amberpoint talked to Cloud Computing, SAAS, Event Processing, Open-Source and Governance.
Separate to this I have had the opportunity to do some training and consulting in the area exposing me to the contracting base and additional government agencies. It is clear that data sharing between agencies appears to be increasing and currently service APIs are seen as the goal.
Vendor presentations by IBM, Microsoft, Oracle, Red Hat and Amberpoint talked to Cloud Computing, SAAS, Event Processing, Open-Source and Governance.
Separate to this I have had the opportunity to do some training and consulting in the area exposing me to the contracting base and additional government agencies. It is clear that data sharing between agencies appears to be increasing and currently service APIs are seen as the goal.
Thursday, March 19, 2009
SOA Architecture and Agile Methodology
Over the past couple of months I have been exposed to colleagues, professional acquaintances, and training that has discussed the merits of Agile Methodologies in creating a loose but improved development organization. One client that I work for has several teams that are employing short iterations and have improved their overall deliver of software functionality. The company has also spent time training the teams via experienced Agilists and employed collaboration software to support epics, mrf, user stories, product backlog etc.
Working in the architecture group, there is currently no process in place but we are considering applying Agile and short 2 week iterations to deliver value to the product teams. In essence have the product teams help define challenging issues to be solved to free them up and allow them to focus on their tactical user stories/development tasks. In addition having the architecture team sit in on the product teams iterations to identify / guide the development teams towards existing services in the domain/enterprise to reduce/eliminate rebuilding existing logic. This can be done by participating in the Iteration Planning Meeting at the beginning of each iteration.
From these experience I will be trying some role/organizational approaches towards SOA in an Agile environment. They include setting up clear versioning policies for the service contracts and using design patterns to decouple the contract from the logic. This will allow the contract to more easily change from its potential tactical definition to a more domain/strategic one.
Working in the architecture group, there is currently no process in place but we are considering applying Agile and short 2 week iterations to deliver value to the product teams. In essence have the product teams help define challenging issues to be solved to free them up and allow them to focus on their tactical user stories/development tasks. In addition having the architecture team sit in on the product teams iterations to identify / guide the development teams towards existing services in the domain/enterprise to reduce/eliminate rebuilding existing logic. This can be done by participating in the Iteration Planning Meeting at the beginning of each iteration.
From these experience I will be trying some role/organizational approaches towards SOA in an Agile environment. They include setting up clear versioning policies for the service contracts and using design patterns to decouple the contract from the logic. This will allow the contract to more easily change from its potential tactical definition to a more domain/strategic one.
Thursday, March 12, 2009
How easy is SOA?
When reading blogs on SOA or technology in general, what strikes me is the amount of misleading information that exists in the space or even worse, the lack of information. When tackling new technologies in open source or standards, the lack of documentation or practical information is quite often missing. Once in awhile, I find a clear and concise document that is able to help me learn a technology rapidly. An example of this was some work I was doing debugging a Hibernate issue. To really understand the process/facilities that Hibernate provides, the base documentation provided a solid basis and was able to get me to completion within a couple of hours.
Compare this with work I was doing with some WS Standards, where the only information I could find was the specification and a poorly documented reference implementation.
As part of my business diversification towards providing training in the SOA and Open-Source marketplace, I will be trying to distill how SOA, the available tools and design standards can be applied to people that have little to no experience. An example of this is a group of QA personnel who I will be training in SOAPUI.
Another group I am training is around building a SOA Application that is front-ended by FLEX and back-ended by MySQL.
My current experiences is always focused on the KISS principle. Don't assume the audience is familiar with XSD, WSDL, Service-Orientation etc.
To date these students are getting the examples and are helping evolve these heterogenous scenarios into potentially valuable training offerings. So I can definitely answer that SOA is not easy however if approached properly, a wide audience can participate and incorporate the core principles and technologies.
Compare this with work I was doing with some WS Standards, where the only information I could find was the specification and a poorly documented reference implementation.
As part of my business diversification towards providing training in the SOA and Open-Source marketplace, I will be trying to distill how SOA, the available tools and design standards can be applied to people that have little to no experience. An example of this is a group of QA personnel who I will be training in SOAPUI.
Another group I am training is around building a SOA Application that is front-ended by FLEX and back-ended by MySQL.
My current experiences is always focused on the KISS principle. Don't assume the audience is familiar with XSD, WSDL, Service-Orientation etc.
To date these students are getting the examples and are helping evolve these heterogenous scenarios into potentially valuable training offerings. So I can definitely answer that SOA is not easy however if approached properly, a wide audience can participate and incorporate the core principles and technologies.
Tuesday, February 3, 2009
"SOA is Dead" Questions
Anne Thomas Manes from Burton Group recently posted an article related to the Death of SOA. Many customers that I work with who are in the middle of SOA Projects had questions on the article. Anne's presentation on SOA Fatigue at the SOA Symposium was also a prelude to this posting. If one examines the article, you can draw the following points:
- SOA Technologies from various vendors have become obtuse, costly and difficult to implement
- Enterprise SOA success in the marketplace is limited to a small collection of customers and is not widely seen due to the amount of effort to establish the entire Inventory.
- Service-orientation principles are still valid and important in providing value to the customer.
- Services should be the focus not SOA.
If one is attempting to apply SOA to a domain or Enterprise, we should revisit the goals of SOA:
- Intrinsic Interoperability
- Vendor Independence
- Increased Federation
- Business and Technology Domain Alignment
- Increased ROI
- Organization Agility
- Reduced IT Burden
These goals are then supported by the following principles of service-orientation
- Standardized Contract
- Loose Coupling
- Reusability
- Abstraction
- Autonomy
- Statelessness
- Discoverability
- Composability
The application of service-orientation helps guide business analysts and architects towards resuable, agnostic services. By following these principles, we in affect are directly supporting interoperability, vendor independence and federation. Service development also benefits from business and technology domain alignment when analyzing existing processes in an Inventory Analysis.
The success of customers I work with has been on supporting a domain versus the entire Enterprise. Success of the domain efforts in several cases has caused the business side of the organization to consolidate functionality in other divisions to leverage the domain services and their demonstrated benefits.
The key in Anne Thomas Manes blog is that the fundamental piece of SOA, the service, is still important. A service is logic that has applied service orientation to a meaningful extent. This in combination with SOA Design Patterns provides the architect/developer with a solid foundation for realizing the benefits. How you the develop, register, host, monitor the service can be done in a heterogeneous way with a wide range of standards, technologies and patterns.
- SOA Technologies from various vendors have become obtuse, costly and difficult to implement
- Enterprise SOA success in the marketplace is limited to a small collection of customers and is not widely seen due to the amount of effort to establish the entire Inventory.
- Service-orientation principles are still valid and important in providing value to the customer.
- Services should be the focus not SOA.
If one is attempting to apply SOA to a domain or Enterprise, we should revisit the goals of SOA:
- Intrinsic Interoperability
- Vendor Independence
- Increased Federation
- Business and Technology Domain Alignment
- Increased ROI
- Organization Agility
- Reduced IT Burden
These goals are then supported by the following principles of service-orientation
- Standardized Contract
- Loose Coupling
- Reusability
- Abstraction
- Autonomy
- Statelessness
- Discoverability
- Composability
The application of service-orientation helps guide business analysts and architects towards resuable, agnostic services. By following these principles, we in affect are directly supporting interoperability, vendor independence and federation. Service development also benefits from business and technology domain alignment when analyzing existing processes in an Inventory Analysis.
The success of customers I work with has been on supporting a domain versus the entire Enterprise. Success of the domain efforts in several cases has caused the business side of the organization to consolidate functionality in other divisions to leverage the domain services and their demonstrated benefits.
The key in Anne Thomas Manes blog is that the fundamental piece of SOA, the service, is still important. A service is logic that has applied service orientation to a meaningful extent. This in combination with SOA Design Patterns provides the architect/developer with a solid foundation for realizing the benefits. How you the develop, register, host, monitor the service can be done in a heterogeneous way with a wide range of standards, technologies and patterns.
Tuesday, January 6, 2009
SOA Design Patterns Online
In a previous post I talked about the first SOA Symposium held in Amsterdam last October. One of the book releases from Thomas Erl was SOA Design Patterns which is now available in an updated form online. Check out www.soapatterns.org. In addition to the published patterns are candidate patterns around REST, binary data transmission and others.
Subscribe to:
Posts (Atom)
