Title: Dave & JP on SCA

From: [email protected] [mailto:[email protected]] On Behalf Of Biske, Todd
Sent: Tuesday, December 20, 2005 10:02 AM
To: [email protected]
Subject: [service-orientated-architecture] Dave & JP on SCA

 

David Linthicum's latest podcast is a discussion with JP on SCA.  It was a pretty entertaining discussion.  JP I had a question for you based on some of your comments that I thought might make for a good discussion.  Near the end of the podcast (about 23 minutes in), you made the comment that you "have yet to figure out what the heck is different between Web Services and BPM and SCA."  You went into some details which I agree with, and since I haven't read the SCA spec yet, I can't go into any details there. What the discussion did remind me of, however, was the challenges we face in trying to achieve reuse.  Reuse is a benefit of SOA, clearly, but I've had many, many discussions with many people on why every piece of reusable logic should not be a web service.

The challenge that's out there is how to facilitate reuse of logic, when the technologies that allow the logic to be reused all have pros and cons associated with them, making them only suitable for certain contexts.  Everyone agrees that services should be coarse grained.  Web Services are a good fit for this, because in the grand scheme of things, the overhead of the SOAP processing has a negligible effect on the overall response time desired by the consumer.  The problem is that granularity is a relative measurement.  The same piece of logic may be the only piece of business processing required by one consumer, whereas another consumer may be using that logic as part of a composite service.  In the latter case, the logic is more fine-grained within the context of the problem.  As a result, Web Services may not be as suitable for this situation.

>>> As stated in my last post responding to Jeff, there is a hint that reuse is the primary goal for SCA, but the communications presented to date do not demonstrate to me that this specification is going in the right direction.  Frankly, I wish Webmethods would contribute some of their IP to the open source community.  They’ve solved this problem very elegantly in their integration tool.  It’s been awhile since I’ve seen the product, but in the older incarnations you could develop services in a number of different languages and expose them to their flow language, which would allow you to wire them together into an aggregate service.  BPEL has some aspects of this capability, but perhaps not enough.  At XMLSolutions, back in 2000, we developed our own XML language to wire together or chain URLs and it was very powerful.

I believe we need to be careful not to develop standards for the sake of developing standards.  Much of SCA can be done with a tool and perhaps it should stay in the tools.  If SCA wants to be an Eclipse standard, then great, good on ya!  If it wants to be the de facto way we describe aggregate services, I’m not a fan at this time.  However, if anyone knows of a simple, open source tool that will allow me to simply aggregate Web Services together without a lot of overhead, please let me know.

This problem isn't new.  In the J2EE space, local EJBs were created to accomodate this.  Even prior to that, most app servers would optimize invocations that were running within the same JVM, minimizing the overhead.  What I've heard about WCF does this as well.  At development time, we get the benefits of WSDL, SOAP, etc., but at runtime, the VMs can optimize the communication to minimize the overhead.  When I saw the spec's title, I was interested whether this was something that was going to try to tackle this problem.  Is it?  Or are we still in a wait and see mode.   Any other comments on this dilemma?  I'd love to hear how others are handling it.

Todd Biske
Software Infrastructure Engineering
A.G. Edwards Technology Group, Inc.
V:(314) 955-6254 F:(314) 955-4055 E:[EMAIL PROTECTED]



-------------------------------------------------------------------------------------
A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
archived and subject to review and/or disclosure to someone other
than the recipient.

-------------------------------------------------------------------------------------



YAHOO! GROUPS LINKS




Reply via email to