|Service Oriented Enterprise
Saturday, October 11, 2003
Microsoft just gets it... Microsoft just plain gets it. They understand web services and they understand developer needs.
Take a look at this screen shot from the MS WSE documentation. One nice set of docs around all the WS-* specs. It is a thing of beauty...
posted by jeff | 8:09 AM
Friday, October 10, 2003
Public SOAP Router I pistol-whipped one of my consultants into putting up a public SOAP router. It is the WSE 2.0 impl. If anyone wants to donate another impl, I'll gladly put that up as well.
For now, there is no dynamic routing algorithm.. just a static routing table. We are going to use 'to' fields in WS-Addressing as the final destination (for now).
We are also hoping to put up an unreliable-router soon (to test WS-ReliableMessaging, along with a static WSRM Policy Assertion).
This is super-duper beta kind of stuff. Send me an email if you are interested in testing out the public router: firstname.lastname@example.org
We are building an HTML front-end so that you can add your own entries but this isn't out yet. Til then, you'll have to email us your endpoint information.
[[try to use 'pistol-whip' in a casual sentence when talking to friends - it will likely bring a smile to your face!]] LOL posted by jeff | 6:20 PM
Microsoft & Amazon link up via web services By integrating Amazon Web Services, Amazon.com Research Services for Microsoft Office System will provide Microsoft Office System users with access to Amazon.com from within Microsoft productivity applications via the Research Task Pane. Users can access Amazon.com information and make purchases without launching a browser or leaving a document, email message, or presentation. For example, a customer reading a bibliography in a Word document could click on a book title and purchase it from within the Research Task Pane without leaving the Word document. Alternatively, a user will be able to add a footnote, bibliography entry and cover art for books without manually entering the information into a document.
posted by jeff | 12:48 PM
Thursday, October 09, 2003
Logical Services In web service composition (service piping, orchestration, etc.) you have the ability to make one service front-end multiple services. In BPEL, every orchestration is exposed as a web service despite the fact that it potentially encapsulates *many* web service calls.
I've blogged in the past about how the granularity of the service shouldn't matter. Granularity should be adjusted on the fly (when possible). I've blogged about *cheats* - that is, in-process calls that never actually used the network services (TCP & HTTP) - or even web service calls that were too lazy to use XML Schema - they realized that they were running in the same JVM or CLR and just used shared memory. These concepts are related to my vision of SODA (a concept popularized by Darryl Plummer at Gartner) or Service Oriented Development of Applications. The fact is that SODA doesn't work unless you cheat. You must have both static and dynamic optimizations of service-to-service calls.
When you do this you begin to realize that the piece of code that you called your 'service' was aggregated with another piece of code also called a 'service'. After a while, you realize that all of your services were really just logical things that could have their boundaries redrawn.
Web services are logical - hell, software is logical. The interfaces, the boundaries, the messages between them - all logical. Thus, the ability to recombine them in new ways is not only possible and practical, but perhaps inevitable. Future SODA tools will have the ability to *compile* multiple services together into single service.
Now, what does *compile* mean? Hmm... interesting question. Well, it could mean actually compiling. Or it could mean orchestrating. Or perhaps, just redelivering the service to a runtime container that knew how to *cheat*. Any way you look at it, the art of SODA will be about the ability to combine services in a variety ways. It should protect the black-boxed nature of the service while still giving the developer all of the functionality and performance of a compiled application.
SODA is the evolution of programming; when should an object be a component? When should a component be a service? If you answered these questions based on interface granularity then you don't understand SODA. posted by jeff | 6:27 PM
Stencil Group Changes Mission: Conspiracy Theorists Ok. Just kidding of course. The Stencil Group does great work - however, I really, really don't understand the conspiracy piece that Bill Robins wrote about at news.com.
Why would IBM and MS share the stage to promote web services? The answer is simple. They need to create a compelling reason for their customers to buy the next generation of software suites. The major advancement in the suites is web services - and yes again, interoperability is required. IBM and MS must do more sessions with top people demonstrating this in order for them to convince the customer base of the primary value proposition.
One more time...
A compelling reason to buy.
Microsoft makes decisions based on making money... selling products... providing value; it is real simple. posted by jeff | 7:36 AM
Tuesday, October 07, 2003
Becky Dias at MS is blogging I just found the blog for Becky Dias, the WSE product manager at Microsoft.
Check out: http://blogs.gotdotnet.com/rdias/
posted by jeff | 7:29 PM
Monday, October 06, 2003
Interwoven release SOA version See:
http://www.interwoven.com/news/press/2003/0721sdk.html posted by jeff | 4:09 PM