deltalounge

For the first time I had to make an integration to a service that had no WSDL deployed with it. Since the (SCA) Composite assumes a WSDL it takes some time to figure out how to realise this. Under default conditions a Reference in a (SCA) Composite in SOA Suite 11g looks something like:

<reference ui:wsdlLocation="SomeDataRef.wsdl"
                   name="SomeDataWebService">
  <interface.wsdl interface="http://ws.deltalounge.net/SomeDataService#wsdl.interface(SomeData)"
                  callbackInterface="http://ws.deltalounge.net/#wsdl.interface(SomeData)"/>
  <binding.ws port="http://ws.deltalounge.net/#wsdl.endpoint(SomeDataService/SomeData_pt)"
              location="http://ws.deltalounge.net/tstservices/SomeDataService?wsdl" />

The location of the binding.ws points to a WSDL. Which is no problem at compile time. However at runtime the WSDL can not be found and an error is raised.
This error can be prevented by pointing to the endpoint instead of to the WSDL. To accomplish this your Reference in a (SCA) Composite in SOA Suite 11g would look something like:

<reference ui:wsdlLocation="SomeDataRef.wsdl"
                   name="SomeDataWebService">
  <interface.wsdl interface="http://ws.deltalounge.net/SomeDataService#wsdl.interface(SomeData)"
                  callbackInterface="http://ws.deltalounge.net/#wsdl.interface(SomeData)"/>
  <binding.ws port="http://ws.deltalounge.net/#wsdl.endpoint(SomeDataService/SomeData_pt)"
              uri="http://ws.deltalounge.net/tst/services/SomeDataService"/>

Now there is an uri in the binding.ws refering to an endpoint.

The agenda for the SOA Symposium 2010 has been posted. Again there are very interesting sessions during this 2 day conference. The largest and most comprehensive in the field of SOA and Cloud Computing. The Real World SOA Case Studies track offers a great opportunity to learn from the experience of others. In this track you will find:

Real-life accounts of successful and failed SOA projects discussed first-hand by those that experienced the project lifecycles and have a story to tell. These veteran practitioners will provide advice and insights regarding challenges, pitfalls, proven practices, and general project information that demonstrates the intricacies of implementing and governing service-oriented solutions in the real world.

I will be presenting the first session in this track on Using a Service Bus to Connect the Supply Chain. If you have any topics or questions in advance that you think I should address, please post them in the comments. Hope to meet you in Berlin.

Although I didn’t attend the Burton Group Catalyst Conference in Prague this week, I was able to get a glimpse using twitter and some blogs. My main focus was on the Life after SOA: Next Generation Application Architecture track. In this post I’ll share some quotes and thoughts with you.

SOA Governance

On governance I like this quote from Anne Thomas Manes:

If you can’t manage and govern your services with a wiki, a registry/repository won’t help you, either.

This goes great with the statement that I’ve put on this blog before that it is not about the tool it is about people and process. Besides that managing a Service Repository also isn’t a Silver Bullet either, it has proven to be very useful for some of our customers.

BPM

Here are some quotes from Mike Rollings on BPM:

Too much focus on business process automation is detrimental to your BPM initiative.

Automation helps reduce human effort, but fixating on automation gets in the way of optimizing the business.

Automation can be an enabler for optimization, however it should never get in it’s way of become some kind of burden. Yes software can help, but software is a means to (process) optimization not an end or a goal.

So far, I am not sure where I stand on the following quote from Anne Thomas Manes:

BPM infrastructure tools: process modeling tool is key. But models are not to be created to generate code.

On one side I’ve worked with tools that generate good code from models. At the same time I’ve worked with analyst and other functional people that do not have the skills to create a model that will result in great software. Please share your thoughts on the subject in the comments!

On October 5 and 6 2010 the worlds largest SOA and Cloud Computing event will be held in Berlin; the SOA Symposium. The International SOA and Cloud Symposium brings together lessons learned and emerging topics from SOA and Cloud projects, practitioners and experts.

There is a call for presentations:

The SOA and Cloud Symposium 2010 program committees invite submissions on all topics related to SOA and Cloud, including but not limited to those listed in the preceding track descriptions. While contributions from consultants and vendors are appreciated, product demonstrations or vendor showcases will not be accepted.

All submissions must be received no later than June 30, 2010. An overview of the tracks can be found here. Other resources:

• My blogpost of the SOA Symposium 2009.
• Presentations from 2009.

After once again looking for good, useful definitions of Services and Process decided to put them here for future reference.

Service Orientation – Paul Allen

The following definitions come from Service Orientation: Winning Strategies and Best Practices by Paul Allen.

A service is functionality that must be specified in the business context and in terms of the contracts between the provider of that functionality and its consumers. Implementation details should not be revealed. The implementation of the service does not have to be automated – it could consist of purely human activity.

A business process is a set of activities that is initiated by an event, transforms information or materials, and produces an output. These sets of activities are either value chains that produce outputs valued by customers or infrastructure processes that produce outputs that are valued by other processes.

With the remark that “a business process is usefully pictured as being composed of re-configurable services”.

A software service is a type of service that is implemented by software and that offers one or more operations (or software functuions).

Web services technology is a set of XML-based industry standards and specifications that specify a communication protocol (SOAP), a definition language (WSDL), and a publish-subscribe registry (UDDI).

Succeeding with SOA and Implementing SOA – Paul C. Brown

The following definitions were taken from Succeeding with SOA by Paul C. Brown. Who also wrote Implementing SOA.

A service is a unit of functionality packaged for convenience and consistent use.

With the remark that typically, this functionality consists of a body of information and a set of operations for managing this information.

A business process is a structured set of activities organized to produce results.

A process, or more specifically a discrete process, is a sequence of distinct activities that produces (or attempts to produce) discrete countable results.

An activity is a function performed by one or more agents that uses on or more inputs and produces one or more results.

SOA Design Patterns- Thomas Erl

This post could simply not exist without quotes from Thomas Erl. A complete list of his books in the Service-Oriented Computing series can be found on soabooks.com.

Services are collections of capabilities. A Service is a unit of solution logic to which service-orientation has been applied to a meaningful extent.

Services exist as physically independent software programs with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing.

A Web service is a body of solution logic that provides a physically decoupled technical contract consiting of a WSDL definition and one or more XML Schema definitions and possible WS-Policy expressions

In a Web service Capabilities are exposed as operations.

Some of the RSA talks are distilled by the folks at CognitiveMedia into abridged animated versions – RSAnimate. Here is one om motivation and drive:

There are loads of examples in litterature but also in more popular books like Freakonomics that:

People respond to incentives

In the animation you’ll see the kind of incentives that work well for tasks that go beyond mechanical skills and that require rudimentary cognitive skills (like conceptual and creative thinking). These incentives include the following aspects :

• Autonomy – Which demands engagement instead of management and control.
• Mastery – It is great fun to learn things and sometimes even be (really) good at something!
• Purpose – Humans are purpose maximizers even more than money maximizers.

Please note that money isn’t one of them. In short for organizations and managers it boils down to:

Treat people as people!

Let me know what you think on this subject in the comments….

Recently I read an extensive blogpost by Frans van Buul on Spring and Java EE. As he points out there are some false arguments in favor of the Spring Framework. It is stated that:

Many of the arguments that have traditionally been brought forward in favor of Spring are invalid or outdated, because they target disadvantages of J2EE 1.4 and prior versions, rather than Java EE 5/6. … the original argument that this is not supported by Java EE is simply gone, and the remaining argument, if present, is much weaker.

If you’re in a position where evaluating these alternatives read the entire blogpost. Generally speaking there is no best way to go. Both are viable frameworks for writing Java applications.

The choice should be made by taking into account the particular requirements and technology strategy of the organizations building and using the application.

If there’s an opportunity we’ll see if we can come up with some rules of thumb for the selection.

Yesterday I attended a Lessons Learned session for a Software Development project where I’ll be involved in the upcoming phase. All participants shared their opinion on the negative and positive experiences. What went well and what needed improvement. Putting all these opinions expressed on Post-It notes in perspective I realized that the major part of the negative experience where from the early days of the project. Whereas the positive experiences seemed to be from the most recent period. This brought me back to one of the models I was taught on Group Development while taking training and coaching courses. It suddenly made sense to me that there had to be a relation with the Tuckman’s Group Development Model.

Tuckman’s Group Development Model

The Group Development Model that was proposed by Bruce Tuckman in 1965 has four phases:

• Forming: Individual roles and responsibilities are unclear. Lots of questions about the team’s purpose, objectives and external relationships. Processes are often ignored. Members test tolerance of system and leader.
• Storming: Clarity of purpose increases but plenty of uncertainties persist. Cliques and factions form and there may be power struggles.
• Norming: Agreement and consensus is largely forms among the team. Roles and responsibilities are clear and accepted. Commitment and unity is strong. The team may engage in fun and social activities.
• Performing: The team knows clearly why it is doing what it is doing. The team has a shared vision and is able to stand on its own feet with no interference or participation from the leader. There is a focus on over-achieving goals.

More in this PDF on Forming, Storming, Norming and Performing.
So in which phase do you think the most fun, excitement and productivity is? And as you guessed this was reflected in the Lessons Learned session mentioned: The negative experiences were during the Storming, and the positive experiences during the Performing phase.

Note that:

These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

It is important to realize this because sometimes a group of people in a meeting go through these same four phases. And if your a real goal oriented person you could try to skip the first two of three steps. That in will have a severe impact on the buy in of the group / team.
The teams that don’t get out of the Storming phase usually deliver no or very low quality software…