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.

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

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.

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.

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.