|
|
| Service Oriented Enterprise |
|
|
Saturday, May 22, 2004 Process Visibility as a Service Should 'Process Visibility' be a service? It has been my experience that most people who look at BPEL solutions want a combination of the following: 1. A way to combine multiple web services into a single service (composition). 2. A method to explicitly define the flow of control between activities (or steps) in a business process. 3. The ability for management to know what step or state a process is in. Number 3 is the Use Case for 'Process Visibility'. So, how do you do this as a service? Well, you still have to identify all of the activities to the degree in which you are interested in visibility. You also have to identify combinations of 'interesting state'. For example, if an order for a part comes in and no inventory is available for that part, well - that is interesting. This becomes a declarative rule applied towards a handful of variable to define a single state of interest. Also, anyone that is participating in providing visibility must be able to identify which instance of a process they are talking about, thus the equivalent of a correlation token must be used. I'm thinking something like this: Key=(ProcessID, InstanceID, CorrelationTokens) updateProcessData( Key, SomeData) It would be easy enough to turn this into an aspect (AOP) in a BPEL engine - but I'm not so sure that you want to bottleneck these calls. I do think it should be an aspect but invoked at the event source. Now that you have a service that is collecting data across a distributed environment, it must tell others about the 'interesting states' that it has encountered. That sounds like a pub/sub problem to me. I don't know... maybe something like this: subscribeProcess(ProcessId, StateID, StateOfInterest) (This implies that it is interested in all process instances that achieve a certain state.) Obviously, the BAM system would end up being a subscriber to this. Hmmm... interesting. Now we have a state machine firing when certain states of interest are achieved. Next up: 'Flow Control as Metadata', followed by 'Service Oriented Metadata' posted by jeff | 8:44 AM Thursday, May 20, 2004 The Systinet Gateway Just some quick highlights on the Systinet Gateway product: Systinet Gateway is able to extend and bridge the following products: IBM WebSphereMQ (formerly MQSeries), TIBCO Rendezvous, and any JMS-based middleware solution. Gateway can extend these MOMs and bridge between combinations of these products. ------------- In essence, the Systinet Gateway modernizes some of the last-gen Queue/Bus products by bridging the gap between proprietary and open WS-* standards. This is nice if you already have an existing product (Tibco/IBM-MQ/JMS-*) in house and want to move down the ServiceNet path. Systinet chose not roll yet another Queue/Bus but instead has placed a wrapper around the best-of-breed that exist today. One thing I'm not sure about is the support for WS-Policy (is that implied?) Also, I'm not sure but it sounds like they do some sort of translation between a WS Endpoint and a Topic (I'm guessing). Is the Gateway a big deal? Yep. The Queue/Bus is commoditized, but the WS-Bus is still emerging. The Gateway must still prove to be performant (minimal overhead) and consistent with the architecture of the products that it front-ends (e.g., how well does it work with clustered versions, does it gracefully start-up/shut-down with the Bus, does it have similar versioning mechanisms, etc.) What does this mean for Systinet? First, it is one of their higher end products ($$$) and will require a more sophisticated sale then what they are used to with Wasp. Second, they will have to convince Tibco/IBM/Sonic/Spirit that they aren't competition, but complementary. Lastly, they will have to fight off the other 'legacy-enablers' like Iona and the adapter players. This product (along with UDDI and their service enablement line) now give companies the tools to turn 'last-gen' into 'next-gen'. So what can we expect next from Systinet? posted by jeff | 5:03 PM Iona to Reduce Number of Press Releases! A representative from Iona has stated that they intend to reduce their number of press releases... or something like that. Actually, I believe what he said was: "Gateways are simplistic -- anyone can write one" - (meaning that even Iona can write one) and... "I'd personally be embarrassed to issue a press release touting a mere gateway." Interesting. Let's take a look at the Iona press releases which are so damn important: May17 IONA Makes Standards Compliance Easier for Telecommunications Equipment Manufacturers May12 Chinese Premier Visits IONA Technologies May10 IONA Joins Telemanagement Forum May04 IONA Puts Developers on the SOA Fast Track Hmmm... they joined an industry group, had a diplomat visit and wrote a white paper. Iona - you kick ass!! Don't bother with those silly press releases about new products - those... well, those are just embarrassing. posted by jeff | 6:09 AM Monday, May 17, 2004 BEA opens up some slots, too From Monster.com: ====================================== Major Duties and Responsibilities: You will join the development team for state-of-the-art BPM application development framework aimed at enabling corporate-level developers to build and deploy scalable, highly-available, web-based enterprise applications involving web services and other B2X e-business applications. Specifically we are seeking a person in our runtime team to help build the Business Process Engineer. Qualifications/Necessary Skills: A related degree and 5-7+ years relevant experience in java programming at the systems level. Must have in-depth expertise with J2EE technologies, enterprise level server development. A solid understanding with BPEL required. =========================================== What no BPELJ required??? posted by jeff | 3:30 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
