|
|
| Service Oriented Enterprise |
|
|
Friday, February 20, 2004 Mach3 Turbo ESB This is a must read: http://www.theonion.com/opinion.php?i=1&o=1 Come on... shouldn't someone do the Turbo ESB??? You're ESB only does queues, routing and transformation! Mine does all that plus [fill in blank]. Think I'm joking... just wait. posted by jeff | 8:14 PM Thursday, February 19, 2004 WebMethods to Close Office, Lay Off Workers I almost missed this: "WebMethods lost $11.1 million in the quarter ended Dec. 31. Since it went public in 2000, WebMethods has only reported a profit in one quarter, $157,000 for the three months ended March 31, 2003. "Their inability to show profitability has been a very sore spot for investors," said David Hilal, an analyst at Friedman, Billings, Ramsey & Co. "They are doing what they can to appease investors." See: http://www.washingtonpost.com/wp-dyn/articles/A20530-2004Feb6.html posted by jeff | 9:57 AM When is a service not an orchestration? When is a service not an orchestration? This is the question that Christoph asks? His point is that all bpel orchestrations 'are services' and if one wanted you could use the orchestration as an agility mechanism. For example, you know that you need a service 'foo' - why not make an orchestration 'foo' where the 'foo' orchestrations calls the 'foo' service. In essence, you treat the orchestration like a proxy to the end service. Christoph goes on to point out that like any proxy-calls, you incur extra overhead. By proxying, you don't tie the 'foo' service directly to the non functional requirements (logging, security checks, business activity monitoring, etc. ) you could add additional steps into the orchestration to perform these for you. Overall, I'd have to agree with where Christoph landed - if the orchestration is time sensitive or doesn't look like it will need any 'decorators' - then just make it a service. If it is part of a long running business process and isn't necessarily time sensitive than consider front-ending the service with an orchestration and add the decorators. In the long run this may kind of 'orchestration-proxy for NFR's' might go away. I'm still a big believer (as is Christoph) in using declarative aspects on services. In this manner, you would declare the decorators on the service and when the service was called and it would trigger the decorator calls (think Aspect Oriented Services). Either way... I'm not sure which one is easier to read / debug. Although it does raise a good point - we probably need a metatag to state if a service call is part of a NFR resolution or if it is a legitimate Functional step in the orchestration... posted by jeff | 7:33 AM Tuesday, February 17, 2004 OpenStorm Launches Today we are officially launching OpenStorm Software. See: http://www.openstorm.com We unofficially launched the company in August of 2002 - but went back into a semi-stealth mode to significantly enhance the product. Our primary goal was simple: create a product that had the simplicity of a Microsoft tool and the scalability and reliability of an IBM tool. We think we did it. First, we took our original .Net orchestration engine and rewrote it in Java for the J2EE platform. The design leverages a message oriented architecture and facilitates logical and physical tiering between the 'communication server' (http, etc.), the message broker (JMS, MSMQ) and the orchestration server (native BPEL, exposed as a service). Then, we rewrote the entire user interface for the developer tooling. We chose the .Net platform for the UI for a couple of reasons: 1. We believe that we can build better interfaces in a shorter period of time than on just about any other platform. 2. We intend on facilitating "Office Orchestration" - enough said. The only issue we are having from a timing perspective is that the .Net Web Service Enhancements (WSE) remain in beta. Thus, we will be waiting on some enhancements before we make the .Net BPEL server available. We also decided that we wouldn't make the first release downloadable. Instead, we are inviting partners and qualified prospects to install the system and work with an assigned OpenStorm team to ensure success. I think the product turned out great. It will serve as the foundation for service oriented integration (A2A and B2B). It will also serve as the underlying engine for the next generation of BPM (Service Oriented, Process Driven Architectures). Lastly, I want to congratulate the team - you kicked ass. They are now busy working on the next release. Stay tuned. posted by jeff | 8:56 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
