I've updated my list of WebSphere conferences, including some new ones in Asia.
See WebSphere Learning Resources (on my wiki) for a list of WebSphere conferences. We've recently announced four in Asia: Bangalore, India; Singapore; Sydney, Australia (technically not is Asia; eh); and Beijing, China. We've also set the dates for IBM WebSphere Portal Technical Conference in the US and in Europe.
I get to go to a lot of our conferences and find that they're really a good way to get an overview of what IBM considers important (SOA!!), how we recommend that you make use of our products to derive business value, and where we're going with our products. They won't teach you everything you need to know about an individual product, although you can get some brief but meaningful depth on individual products; but they will teach you about what's going on with IBM in general. For example, see my notes from WebSphere Technical Exchange 2006.[Read More]
Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: June 2007 X
Search Google for images of WebSphere and what do you find?
My colleague Matt Rollo points out: If you search for "WebSphere" in Google image search, besides the usual pictures of IBM marketing materials and screen shots, picture #43 (or so) is a person. A familiar looking person. In fact, it's my picture. So, like Matt says, you can call me "Mr. WebSphere."
Ironically, if you search for images of "Woolf", after numerous pictures of Virginia Woolf (a distant relative), I'm picture #57. So I'm easier to find under "WebSphere" than my own last name.
Clearly, only one conclusion can be reached: IBM's not paying me enough for promoting its products![Read More]
How do you declaratively specify the behavior of a service?
It's easy, or at least possible, to specify the declared interface for a service. A service's interface captures the signatures for invoking it and defines the data formats for exchanging parameters and return types between the service consumer and service provider. Such well-defined interfaces make integration between components (objects, services, applications) much less error-prone and problem determination much more definitive. But as the name "interface" implies, this only captures how to invoke a service; it does not provide an objective description of what the service does.
Right now, the best way I know to capture intended behavior for a service is using use cases and unit tests. In "Streamline SOA development using service mocks," I call these service use cases and service tests. Service use cases are a human-language description of a service that people understand. Service tests are a programmatic equivalent of the observable effects of those use cases; tests measure the behavior of a service and judge whether it conforms correctly to the intentions described in the use cases.
However, specifying behavior really needs to be more declarative than use cases and unit tests can be. An interface is declarative; either an implementation fulfills the contract or it doesn't. There seems to be no similarly declarative way to specify the behavior of a service. I think that business semantic modeling may be very helpful for capturing the behavior of an SOA service.
"Business semantic model" is a term getting tossed around in SOA circles these days. Unfortunately, I can't find a simple definition that says exactly what it is. The best source I've found for it is a paper that seems to be from 2004, "Unifying Data, Documents, and Processes." Yup, those sound like good things to unify. The business semantic model develops a uniform data model for the enterprise and captures the meaning of the data objects. What seems to be the key is the meaning of the objects (hence the word "semantic").
A similar term is "business process semantic model" (BPSM), which is being developed by the BPMI part of the OMG. According to Essential Business Process Modeling, BPSM is a metamodel for business process definition model (BPDM), a common model for all business process models. A Google book excerpt shows BPMI's recommended BPM stack. This is all very interesting; but will it lead to being able to declaratively describe the behavior expected of a service?[Read More]