Modeling for SOA
In our survey (see below if you have not yet completed) one of the questions asks respondents about their use of SOA. Although we are still in the data gathering phase, the results so far show a clear majority are committed to the approach.
In answer to the question "Is there a commitment to SOA?" 65 percent answer YES. However when we look at the justification for SOA investment we see that whilst SOA is understood to be the strategic direction, not surprisingly integration and cost reduction are overwhelmingly today's priorities.
We also asked about business awareness and the results show quite low business sponsor awareness of the use of Web services with 85 percent reporting either low or medium awareness. In contrast IT awareness is correspondingly high.
We shouldn't be too surprised at these (admittedly interim) results. Web services have been slow off the block for reasons we all understand and the macro economic situation continues to cast a dark shadow over all IT activity. However with maturing tools and platforms, plus positive news on the WS-Security front, many are now thinking hard about where Web services should be used for business advantage.
As with all new technologies, the entire industry and its customers have been strongly focused on the technologies. Recently we have observed many organizations questioning the justification for Web services; that many potential application areas can adequately be served by existing infrastructures at lower cost and risk. One reason for this is that the thinking is technology led. "Here's a neat piece of technology, now where shall I use it!" What's needed is modeling techniques that are designed to support identification and triage of appropriate application architectures.
But it must be said that there has been very little activity completed in the area of methods or processes for modeling and specification. Yet there is a real need for fresh thinking in this area. Let's examine some of the key characteristics of SOA, and consider how these create a demand for fresh thinking in the modeling arena.
SOA requirements for modeling
Business Level Services - Services are published at a level of abstraction that corresponds to real world activity and recognizable business function. The really compelling aspect of this is the opportunity to implement comprehensive alignment and integration of the service life cycle with the business product and/or process life cycle.
Service Based Collaboration - Although services are being widely used internally and for integration purposes this technical orientation will change soon enough. services will increasingly mirror real world business activity, such that data is obtained from the real source in real time, that combinations of services from collaborating organizations cooperate to provide value added services. Whilst there will be infrastructural differences covering matters such as security between internal and externally supplied services, increasingly there will be a common service model that allows seamless operation of business processes internal and external to the enterprise. Although services may be simple, they may also be aggregated from different sources, again reflecting real world business activities. There is clearly a real requirement for service interaction and dependency modeling.
Separation of Interface from Implementation - A core tenet of SOA is that it's the interface (as opposed to the application) that is integrated, in a manner that the consumer has no visibility of the implementation. Some call this "Interface Based Design", a well understood technique from Component Based Development. However this is a rather technical perspective. Services are offered at a business level of abstraction, which renders the interface a business interface, and this generally means a contract, which is expressed in XML.
The importance of the contract in SOA cannot be overestimated. The formal contract is the device that allows us to create virtual businesses, formalize system and scope boundaries, minimize dependencies and maximize adaptability, use black box testing and have a choice of services and more easily change supplier. Although there is some work in progress to bring Design by Contract into UML, and a vague intent to formalize contract elements in BPEL, this looks like an area with a lot of outstanding issues.
Separation between Provider and Consumer - Among other things, service-oriented architectures must be designed with a view to the ease of management - including supply risk management. If the enterprise is dependent upon a few key service providers, this represents a potential risk to the enterprise. This leads to a design goal of making service specifications as general as possible, which of course brings us directly into conflict with performance objectives.
From a process perspective we see only one modeling process and tool vendor - Select Business Systems, that have long recognized the requirement to separate and manage the interaction between supplier and consumer, and they embed this separation into their tools and processes. For the rest of the industry it appears that provider consumer is simply a class naming system.
We are nearing the point where Web services technologies, tools and platforms actually work. The big question then is what do we use them for? There is a real danger that we will get into the territory of Web services being used inappropriately because architects and designers are, consciously or unconsciously looking for problems on which to try out the new technologies. What we urgently need is a better understanding of the practical application of services, and a modeling system that assists us to identify, justify and develop high quality services.
In our report in this month's CBDI Journal we provide architects, analysts and designers with guidance on this important topic. The above thoughts are merely a snapshot of the issues and modeling considerations, which we cover in the report and also in our new workshop products. See links below.
Let us know what you think. We welcome feedback to email@example.com.
CBDi Report: Best Practice Report: Modeling for SOA
What modeling approach is required to implement a service-oriented architecture? We consider how the modeling process needs to change to reflect quite different concerns, and discuss techniques and standards. Report available to Silver and Gold members.
CBDi Web Services Survey
If you have experience with Web services, please take the 10 minutes to complete the survey. You will be asked to login with your Bronze, Silver or Gold registration details. The results will be made available to all members.
Copyright CBDi Forum Limited 2003. The CBDi Forum is an analysis firm and think tank, providing insight on component and Web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.