RE: [service-orientated-architecture] Re: What is a "well defined interface"?

Fri, 03 Mar 2006 13:32:38 -0800

+1 to the ideas being put forth here that the separation of infrastructure in support of a SOA, such as security infrastructure and SOAP intermediaries is a great way to approach “reuse” in a SOA.  I also agree that reusable business services are a great benefit of a SOA, yet it is an ancillary one.  The most important benefit of adopting a SOA should flexibility of the processes that control the interaction between the services, not reuse.   The service interfaces you define should keep that in mind as a goal.  The flexibility that you should achieve in building a SOA is to be able to build composite SOA apps that represent business processes to automate business functions.  One thing that I have learned from talking to many organizations that have built SOAs is that no matter how much up-front planning you do, you never get your service definitions and their interfaces right the first time.  This is in part due to learning as you go, but also more importantly due to constantly changing business requirements.  Sometimes the changing business requirements come from your own business people as they start to see and understand the benefits of your SOA projects as they come to fruition.  Other times the changing requirements are due to external forces that cause your business to rethink how it operates.

 

To that end, you need to build your service interfaces such that they can be document-centric, where the message schema in the WSDL is the interface.  Each service interface needs to be self-contained such that it may communicate more information that it individually needs to work on.  For example, a PurchaseOrder document which includes a <ShipTo>, <BillTo>, and <lineItem> information may be embodied in a service request to multiple services in a business process, and each service may only operate on their respective parts of the request (message).  The services and their dependencies need to be thought of in the context of the broader processes that are going to be sharing that service with other services.  The flexibility comes into play when a process needs to be altered, or new data needs to be introduced to a process.  This can result in individual services being upgraded or swapped out.  The trick is to be able to make these alterations without needing to go back and change all of the services involved—only the ones nearest to change if at all.  The process that controls the interaction can be modified to include a mediation service to transform and enrich the data embodied in the service request to accommodate the new functionality or support the format of the new service being swapped in.  After putting such a process in place, you may deem that its more appropriate to split off those elements into separate requests and farm them out individually to their respective Shipping, Billing, and Inventory applications.  This can be done by inserting a splitter service into the path of a service request as an intermediary to perform that task.  The key point here is that because you started more broadly, you can modify the process that controls the SOA interaction to split off to different services and even route back to an aggregation service when they are completed.  In that scenario the original service interfaces of the services at the front of the process and at the end of it don’t need to be revisited, only the ones in the middle do.

Dave

 

From: [email protected] [mailto:[email protected]] On Behalf Of Todd Biske
Sent: Thursday, March 02, 2006 11:52 PM
To: [email protected]
Subject: Re: [service-orientated-architecture] Re: What is a "well defined interface"?

 

One challenge I've faced when discussing reuse is that not everything that is reusable should be a service.  In fact, most of the reusable items that come to mind fall into two categories:

1) Things that belong in a reusable class library.  After all, two of the best examples of reuse are the rich functionality provided by the .NET and Java EE frameworks.  

2) Things that should be externalized from the application and be implicitly executed through declarative policies.  As a later post already pointed out, this gets into the world of aspect-oriented programming.  It also is well suited for SOAP mediation, as Anne points out. 

 

SOA doesn't necessarily have to be about reuse, although it is a benefit.  I'm a huge proponent of reuse, but I also think the more important factor is to place interfaces at the right places so that the units of work can be combined in new ways in response to business change, which may imply turning the old ways off. The logic still remains, we've just combined it in a new, interesting ways, however it may still only be used in one place.   

 

The items that Anne called out are all good starting points.  Just don't automatically assume they should all be implemented as services.  In some cases, these infrastructure capabilities should be external services, in other cases, an aspect-oriented approach or a class library may be the best choice.

 

-tb

 

 

On Mar 2, 2006, at 6:25 AM, Anne Thomas Manes wrote:



The advice I give to my clients is to start their reuse efforts with infrastructure functionality -- things like authentication, authorization, auditing, cryptography, logging, monitoring, caching, etc. One of the things I like best about SOAP is that it enables clean separation of infrastructure from business logic via the SOAP mediation model.

This approach brings two advantages: it is something that can be done reasonably well by an IT group without a huge amount of collaboration with all business groups that will use the services, and it gives the IT group more control over policy enforcement.

One of my clients (a Fortune 50 financial conglomerate) estimates that 30% of its current IT budget is spent on infrastructure functionality -- which currently is reimplemented in every application. By externalizing this functionality into reusable services, they could potentially save hundreds of millions of dollars a year. They would also have much better control of security and management, and they would ensure much more consistent enforcement of policy.

Another sweet opportunity for reuse is in response to government regulations. For example, anytime someone requests to open an account, a financial institution is required to check a government database to ensure that the person is not a known financeer of terrorists. Rather than implement this code in every line of business for every type of account, this code should be implemented as a shared service.

Anne

On 3/2/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:

Alexander Johannesen wrote:

On 3/2/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:

> You read a lot about enabling service re-use, but very little about organizations that
> actually achieve it on anything beyond a trivial scale.

I guess for this sentance to work, you need to define that scale. Number of applications using the service? Transactions per second? Business importance?

I was thinking about the first of these, which I would rephrase as the "number of services that are used in more than one process".  As I wrote in the last email:



are many services ever used in more than one process without significant change?

Some more on this theme ...

I spent some time in 2001 working with a software house that was building a life insurance application out of components, which interacted via Web services.   This application had to be generic - i.e., in principle be usable by any company selling life insurance.  So it was a testbed not only for SOA technology (since this was early days for SOAP etc) but also for SOA principles (in particular, enabling service reuse).

What they ended up with is a set of services that were fantastically complex to invoke.  To hook them up into a useful process, you needed not only to have a very strong grasp of life insurance (the sort of understanding an actuary has) but also of their particular approach to application design (what all the complex types were for, and what their various nested fields meant).

Now, I didn't have much to do with the design of  their application (I was building a particular one of the components, for process modelling and execution, not specific to life insurance, that eventually became RADRunner), so I am not qualified to say whether or not they could have done things differently.  But I suspect that there may be a general problem here - particularly since my experience with ERP, described in the last email, shows the same forces at work.

Stepping back for a moment, the use of patterns and refactoring has been revolutionizing software design across the board for about 10 years now.  But these techniques do not help make software simpler, just better structured.  And perhaps software cannot be made simpler, since in the end it has to reflect the real-world uses to which it will be put.  So I think it is very hard to build services that are genuinely re-usable in many different processes - not impossible, just hard - and I wonder:

  • How many organizations are doing it on more than an ad-hoc basis
  • What sort of services they have made re-usable - are they very simple? very complex? somewhere in the middle?
  • Whether the financial investment in making these services re-usable was worth it.

Anyone got any figures?  Or tales to tell of service re-use in unconnected processes?  To my mind, there is a fundamental axiom of SOA that needs examining - that service re-use gives ROI.  I wouldn't bet on it, myself, and might write something on the subject.  But before I do, I would be interested to hear of group members experiences.  Perhaps I am completely wrong, and organizations all over the world are busy re-using all kinds of services like crazy without having spent a fortune achieving and maintaining this IT nirvana - if so, it would be interesting to know about them!



-- 



All the best

Keith



http://keith.harrison-broninski.info

SPONSORED LINKS

Computer software

Computer aided design software

Computer job

Soa

Service-oriented architecture

 

 

YAHOO! GROUPS LINKS

 

 

 

YAHOO! GROUPS LINKS

 

 

 

 

 



SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



Reply via email to