"Inside Out is done within seconds"
I heard this statement by a middleware expert who complained that he had to model A2X Enterprise Services within the Enterprise Service Registry while exposing a function group via SE80 is done within seconds. In this situation I realized that many developers know the basics of good programming but they don't have the same experience when using web service technology. So if you prefer the Inside Out approach you should ask yourself the following:
- How do you get a common model of your data types?
- Do you think Inside Out services are easy to consume? Do they have proper naming conventions?
- How do you ensure that the services are neither to fine nor to coarse grained?
- What about quality standards like idempotency?
- And what about change strategies? Is the a programming for a First One Wins update strategy?
In fact the list is much longer and contains the experience of dozens and hundreds of SOA projects. Many of them failed - and from the ones who succeeded software scientists and architects learned from them and lots of that knowledge was condensed to SAP guidelines for finding, modelling and implementing Enterprise Services.
Of course "Inside Out" development of Web Services is appropriate for a quick and pragmatic solution but the usage as basis of an SOA approach is considered harmful.
"Wannabe" Enterprise Services
When I was younger I played the Japanese game of Go. I learned the basics of good shape and efficiency and started to learn Joseki which are special pattern comparable to patterns in programming languages. I applied them to my game and as a consequence I became lost my games. Why? It doesn't suffice to imitate good style - neither in the game of Go nor in programming. You have to understand a pattern, it's strengths and weaknesses before you can start to use it.
So it doesn't suffice to imitate SAP standard services - you have to understand the concepts behind them:
- What's are the differences between change and update services?
- Do you understand communication patterns of Enterprise Service? Do you know about information and notification?
- Do you know who to implement asynchronous services?
If you don't have the answers to those questions I recommend that you should try to understand get deeper into the topic.
"SOAP is already legacy"
I heard this statement form SAP Mentor DJ Adams at SAP Inside Track Bonn. He criticized the complexity of Web Services standards and web as well as enterprise architecture made of WSDL Web Services. He gave good reasons for this statement. Let me mention two:
- SOAP and related standards are much too complex.
- But even with this complexity the usage of SOAP and WSDL don't lead neither to syntactic nor semantic interoperability.
Of course standard experts working for SAP know these arguments and they decided to create a stack of standards as well as guidelines that are the basis for enterprise SOA. Without those standards programmers and solution architects are doomed to create the worst integration scenarios ever because of the lack of established quality and architectural standards.
"SOA by Design" vs. "SOA by Controlled Evolution"
Is "SOA By Design" the answer to all problems? In fact "SOA BY Design" approaches have defined governance processes. In my opinion enterprise architects should know the foundations of those methodologies but I believe neither SAP customers nor partners will be able to apply heavyweight governance processes. The reason is simple: we have to do system integration and we don't have the resources to set up a SOA project which creates a detailed landscape of all IT and non IT based business process of our company (resp. the ones of our customers in case of an ISV) unless we create our fist Web Service. If you have other contradicting information please feel free to contact me.
It seems to me that "controlled" evolution could be a valid compromise between the need of methodology, governance and rules you need to introduce SOA in your company on the one hand and pragmatism and agility on the other hand. The reason is that Enterprise Architects as well as developers have to use established quality and architectural standards that form the basis of SOA implementation in your company.
Keep yourself informed!
Everything you need to know about Enterprise SOA is already written down. The SAP Press Book Developing Enterprise Services for SAP was one of the most useful and eye opening books I read in the last time. I was really shocked when I heard that it is no bestseller. I recommend that every enterprise architect and system integrator should study it. When integration scenarios become more and more important even ABAP developers will have to know most parts of the book.
There are a lot papers about Enterprise SOA and SOA technology within SAP NetWeaver on SDN. Here are only a few of my favourite links:
Summary
It seems to me that Web Services are a field where reason turns to unreason:
- Programmers and even consultants from SAP who are talking about performance all the time (and even use stored procedures) are starting to use Web Services instead of EJB calls even within there core applications in performance critical contexts even when there's no need to do so.
- Programmers who use naming conventions in ABAP or Java don't care about XML namespaces and XML naming and design rules.
- Programmers who know about abstract data types and classes are forgetting everything about standardization and reuse when dealing with XML data types.
I may be sound too harsh but lots of professionals turn into amateurs when dealing with Web Services. Do you know why? Is it because Web Services are cool and SAP NetWeaver technology so easy to use? Do we really need rigid governance processes for Web Services?
