by Rajat Bhatla
I had attended a workshop on understanding IBM SOA technologies at IBM South Bank London a few months ago. At the time I was also on a project where we were defining an enterprise SOA based landscape. So it was quite a good timing with live practical experience on one side and IBM on the other. It proved a rich learning experience, combined with interactions with SOA practitioners from different streams, hands on labs and highly experienced IBM staff. In this post I’ll just focus on the Websphere stack of tools that we were exposed to, and my takeaway feelings about the set of products that we did hands on with.
By Anuj Sethi
I would like to begin by stating that the title above can be interpreted in multiple ways (yes it’s the word ‘Service’). Hopefully by the end of this blog you will be able to appreciate why I have stated so.
In most organisations the IT part has two sub-organisations: One responsible for design/develops the software (equivalent of a car manufacturing plant, at some level) and another which actually support the running software (equivalent of a car service station). The focus of this blog is on the latter.
One of the fundamentals about SOA that every enterprise needs to understand is where they stand today before starting the SOA journey – are they ready to take the plunge? Understanding this would give a quick overview of the organisations readiness and maturity of SOA. Thereby ensuring that the common SOA pitfalls are avoided and right strategy and associated programme/initiatives are identified for starting SOA journey for the organisation.
SOA has now become main stream. Organizations are slowly aligning themselves to implement SOA to realize the benefits. And then suddenly we have "Cloud Computing"; the new kid in the block. It has generated unprecedented hype. Gartner’s Senior Analyst Ben Pring has mentioned that "Cloud computing has become the phrase du joir". It is difficult not giving enough attention to it. Not to miss the wave, we see cloud vendors pop up every day providing a variety of services. It is being discussed in almost all the IT boardrooms. And rightly so, people have started to realize that this is not just any buzz. It promises to do to IT, what Internet did to business in the early 90’s; a paradigm shift.
Every web service Designer and Developer possibly have come across service naming standards or best practices in one form or the other. While I do not want to dispute the fact that standards are needed for enforcing good practices that goes a long way in software maintainability and manageability, but then trying to follow a standard without completely understanding the philosophy behind it may not produce optimal results. Now, I do not want to get into pros and cons of particular semantics of service naming either, e.g., naming conventions such as using a verb+noun pair for naming a service, using camel case etc. I will pretty much follow those widely used conventions without a debate. I will rather try to throw some lights on the common-sense and practical factors that may make service naming less creative and more predictable. Comments and debates welcome.
I was the chair for SOPOSE 2009, the fourth international workshop Service and Process oriented Software Engineering (http://www.dsl.uow.edu.au/sopose/index.php ), the workshop co-located with SCC 2009. The workshop aimed at addressing software engineering issues related to constructing service oriented architecture and business process management.
by Murteza Salemi
The fundamental rethink approach required for implementing SOA initiative in an enterprise is that SOA program should be driven by business (business driven SOA) and not technology or vendor products. Furthermore, the initiative must target specific goals and offer ways of objectives measurement.
by Murteza SalemiOASIS, OMG, and The Open Group, the three largest standards bodies for SOA and Web services have collaborated on jointly publishing a new white paper called "Navigating the SOA Open Standards Landscape Around Architecture."
The significance about the paper is to reiterate the message that SOA is not about technology but rather the Architecture with big "A". The paper also outlines the agreement on core SOA concepts and terminologies which brings harmony and more or less coordination to these diverse concepts which are very similar in the essence.