Showing posts with label soa. Show all posts
Showing posts with label soa. Show all posts

Wednesday, 2 January 2008

Featured book: SOA in Practice

I've recently finished my reading of SOA in Practice by Nicolai Josuttis. Nicolai is an experienced software developer and architect who has helped to establish the SOAs at the major German telecommunication and mobile telecommunication companies. In SOA in Practice he's sharing his know-how made during those projects with the reader. And from the first moment you've got the feeling that this is no lengthy theoretical introduction. Instead the author uses many examples to demonstrate the pitfalls during the establishment and operation of SOA environments and how to evade them. A must-have book for any SOA architect.

Sunday, 16 September 2007

SOA Days 2007

This week I've been in Bonn at the SOA Says 2007 Technology Conference. The program was a good mix of key notes, practice reports, and networking. I'll work out an abstract for my colleagues the next days. The most important facts are: The hype is over, in the Gartner hype cycle it's now somewhere between the Trough of Disillusionment and the Slope of Enlightenment. The number of working SOAs is growing, the greatest startet in the late 90s, but without the name SOA. Very often asynchronous message queueing is used instead of web services, service orchestration using BPEL is not allways a topic, and governance and a repository are important when the number of services grows up to several hundred or thousands. So nothing real new, but the talks contained some nice details and ideas.

One quote I've liked the most was by Eclipse Foundation Executive Director Mike Milinkovich: "You know what software development is? Doing the same over and over again." He told this in the context of constantly recurring ideas in new shapes. When I think about the ages of Smalltalk, Lisp/Scheme, Prolog, Erlang, relational and object-oriented DBMS, CORBA, TCP/IP, and several more, I allways feel that there happened nothing real new during the last years. Only variations, most times not better than the original. So it's really important to get the conceptional ideas behind of them, the paradigms and patterns, to make the best out of the technology of today.

Another thing I've done during the train travel and at the evenings in the hotel has been some development in Erlang. I'm still impressed and make good improvements. So my next entry will be about it.

Thursday, 25 January 2007

OOP 2007 - SOA governance and lifecycle management

The last track today has been about governance and lifecycle management as critical success factors of an SOA by Andy Wolf. I'm currently writing a concept for the development, introduction, and maintenance of service-oriented architectures. So I've allready covered serveral of the aspects presented in this track. But his papers are much more detailed and contain new or better formulated items. This will make my life more easy. *grin*

OOP 2007 - SOA case studies

Today two case studies for service-oriented architecures provided a deeper look into real live tasks and problems. Both environments, LifeSensor and VR-Services, have started several years ago due to different reasons. The requirement for felexibility and customizable communications with different service providers where common.

Interestingly they both made some equal experiences and choosed equal ways. So there is much communication needed due to the many involved teams when discussing the different topics. The spreading of operating department, IT department, management, and more reflect the spreading of the owner of the services. Also there is currently no good tooling for development, refactoring, version management, and automated testing. Know procedures from the usal programming aren't usable here. This is one of the reasons why I'll continue to think about Smalltalk as an SOA platform. Adapters to web services and other data sources or service providers can as easily be developed as business processes or transformations.

Both also created normative messages representing the business objects. But the discussion to standardize them between all service providers are difficult and last long. For a better acceptance of their solution they created high level APIs which encapsulate aspects like the communication, the message creation, error handling, and encription.

So the conclusion has been positive. But it takes a long time and much effort to establish an SOA. Everyone should keep this in mind.

Tuesday, 23 January 2007

OOP 2007 - SOA is a paradigm, no technology

Major part today have been three tracks about SOA. All three pointed out that SOA is no technology. It is a paradigm for scalability, flexibility, and fault tolerance. Services are lose coupled and have different owners. It is a long-term journey to establish a service-oriented architecture, starting with small projects, and needing full management support. A central team has to control the services without acting as a bottleneck. There are many more aspects, I'll cover them in future.

But there have been two interesting issues for me: The first is the discussion of CORBA against SOAP as the transportation protocol. CORBA doesn't seem to be dead, even if the WS* hype gives the impression. But for many people XML often seems too bloated. This is no statement against XML, but it has to be used the right way. Also SOAP is stateless what is a big minus for many people. The advantage on the other hand are technologies like XSLT for transformation or XPath for navigation inside an XML based message. Also XML schema provides constraints so that the data can be validated automaticly. But even if these are strong arguments I'm more pro CORBA, I don't know why. *smile*

The second issue are the different opinions about a common data model between all the services. It enables a simple communication if it is defined for a specific application domain and all involved services support it. But this standardization is also the big problem. It is really difficult to define those common structures if the ownership of the services is distributed. So the other opinion is to use only very simple data types, if possible no structures, try to keep the services generic and use mappings and special document schemas for the transportation between two partners. I'm currently evaluating the first idea. We'll see how it work.

Monday, 22 January 2007

OOP 2007 - How software as a service changes everything

I arrived at the conference in the late afternoon. After checking in I looked around a bit and then took part in my first nightschool. It has been "How Software as a Service Changes Everything" by Brian Behlendorf of CollabNet. Based on their experiences he described how the business model of SaaS works, what to consider and where he sees it in four years. He has a very wide idea of what services are. So it's a kind of enhanced outsourcing what he describes. But when speaking about their own products it is the collaboration suite based on SVN and surrounded with web applications, e.g. for issue tracking. Especially those closed systems are very suitable. Together with the idea of providing every functionality also as an API service, e.g. a web service, could be a good base for service-oriented applications developed and maintained by the customer.