Using Ruby Fibers for Async I/O: NeverBlock and Revactor
Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.
Tracking change and innovation in the enterprise software development community
Posted by Mark Little on Jan 16, 2008 06:28 AM
Duane Nickull, OASIS SOA-RM chair and Senior Technology Evangelist at Adobe, has announced that they have just released a new white paper covering specialized message patterns for SOA. As Duane says:The paper looks into specialized messaging patterns for Service Oriented Architecture (SOA). Most people still mistakenly believe that SOA is limited to request-response. Such is far from the truth as most standards work on SOA now recognizes alternative patterns such as subscribe-push and probe-match.Duane discusses a close relationship between Web 2.0 and SOA:
... Web 2.0, is not defined as a static architecture. Web 2.0 can be generally characterized as a common set of architecture and design patterns, which can be implemented in multiple contexts. The list of common patterns includes the Mashup, Collaboration-Participation, Software as a Service (SaaS), Semantic Tagging (folksonomy), and Rich User Experience (also known as Rich Internet Application) patterns among others. These are augmented with themes for software architects such as trusting your users and harnessing collective intelligence. Most Web 2.0 architecture patterns rely on Service Oriented Architecture in order to function.Fortunately the paper includes a nice overview of SOA concepts for those not familiar. It also manages to discuss that perennial flame-war candidate, the role that ESBs can play in a SOA infrastructure:
When designing Web 2.0 applications based on these patterns, architects often have highly specialized requirements for moving data. Enterprise adoption of these patterns requires special considerations for scalability, flexibility (in terms of multiple message exchange patterns), and the ability to deliver these services to a multitude of disparate consumers. Architects often need to expand data interchanges beyond simple request-response patterns and adopt more robust message exchange patterns, triggered by multiple types of events. As a result, many specialized platforms are evolving to meet these needs.
The common service bus is really a virtual environment whereby services are made available to all potential consumers on a fabric. This is typically referred to as an Enterprise Service Bus (ESB) and has a collection of specialized subcomponents including naming and lookup directories, registry-repositories, and service provider interfaces (for connecting capabilities and integrating systems) as well as a standardized collection of standards and protocols to make communications seamless across all connected devices. Advanced ESB vendors have tools that can aggregate services into complex processes and workflows.And as you might expect given Duane (and Adobe's) history, there's a nice reference architecture for SOA and Web 2.0 that the paper uses when discussing the points the authors want to make. According to the paper, the core axioms of SOA are:
Services themselves should be treated as subservient to the higher level system or systems that use them. If you are deploying services to be part of an automated process management system, the services themselves should not know (or care) what they are being used for.The first 10 pages of the report are a good overview of SOA, with obvious input from the authors' real-world experiences. Solely for that reason, it is worth reading. Section 4 discusses the different message exchange patterns that can arise within SOA-based applications:
... keep the service consumers agnostic to how the services are delivering their functionality. This results in a clean decoupling of components, another architecturally elegant feature of modern service oriented systems. Having dependencies on knowing the internal working of the services functionality is another anti-pattern of SOA and should also be avoided
The Key to SOA Governance: Understanding the Essence of Business
WebSphere Virtual Enterprise 3 minute demo
The Agile Business Analyst: Skills and Techniques needed for Agile
Rainmaking - IBM's software virtualization strategy (Jerry Cuomo CTO blog)
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
What does "fabric" mean in "several endpoints on a single fabric"? "fabric" is used a second time in the paper: "The common service bus is really a virtual environment whereby services are made available to all potential consumers on a fabric." How is anybody supposed to understand this?
Hopefully this will be a start... http://www.ebizq.net/topics/esb/features/6132.html?&pp=1 IS SOA FABRIC THE ANSWER? SOA fabric is a new name for the combination of a Web Services platform and a Web Services management environment. In 2002 and 2003, Susan Aldrich covered this space extensively for the Patricia Seybold Group under the then-moniker, “Web Services backplane.”*3 Essentially, in an SOA fabric, intermediary (agent) services are employed to perform the routing, transformation, security, and management tasks required for effective implementation of an enterprise-scale SOA. The intermediaries intercept requests (messages) as they traverse between client (consumer) and service (producer). The SOA fabric consists of intermediaries, registry, and policy components. The intermediaries are deployed in the Web Service execution environment, in the J2EE or .Net container. The underlying assumption in SOA fabric is that all services participating in the SOA are Web Services. SOA fabric is best suited to composite application development—the first SOA style, which has primarily synchronous interactions. While some SOA fabric vendors are starting to implement asynchronous support to comply with the WS-Rel* specs,*4 many more are advertising their ability to integrate with ESBs to support integration and the second SOA style: event-driven/process-driven SOA.
Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.
Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.
Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.
David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.
Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.
Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.
2 comments
Reply