Use SCA to Simplify the Development and Delivery of Service-Based Applications
Service Component Architecture (SCA) is a new programming model that enables developers to build distributed applications more efficiently and effectively than previous technologies. In Understanding SCA (Service Component Architecture), two leading experts offer the first complete and independent guide to SCA. Drawing on extensive experience both developing the SCA standards and implementing large-scale SCA applications, Jim Marino and Michael Rowley provide an insider's perspective for developers and technical managers tasked with architecting and implementing enterprise systems. Rather than simply providing a technology overview, the authors draw on their practical experiences with SCA, explaining
- The full history behind SCA
- How SCA fits with other enterprise technologies such as JEE, .NET, Web Services, and BPEL
- All the major SCA concepts including composition, policy, wires, and bindings
- Best practices for designing SCA applications
- Using SCA with Web Services, Message-Oriented Middleware, BPEL, JPA, and Servlets
Understanding SCA (Service Component Architecture) provides the background necessary to make informed decisions about when and how to best use SCA to build enterprise applications.
|Series:||Independent Technology Guides|
|Sold by:||Barnes & Noble|
|File size:||11 MB|
|Note:||This product may take a few minutes to download.|
About the Author
Jim Marino, Ph.D., is Principal at Metaform Systems, where he provides strategic planning, architecture assistance, and training to clients worldwide. Jim is also one of the architects of the Fabric3 SCA runtime. Prior to joining Metaform Systems, Jim was Director of Technology at BEA Systems, where he was involved with the development of Service Component Architecture from its inception.
Michael Rowley, Ph.D., is the CTO of Active Endpoints, Inc. He has been involved in the development of SCA from early in its development and has contributed to 12 of the 15 SCA specifications that were published as part of the Open Service- Oriented Architecture (OSOA) collaboration. He was also an original member of the Open Component Service Architecture (OpenCSA) steering committee, which is the OASIS steering committee that oversees the work of the various SCA technical committees. Before joining Active Endpoints, he was a Director of Technology at BEA Systems where, in addition to working on SCA, he also helped develop the BPELJ extension to BPEL and was involved in the early development of BEA’s event processing and service bus products. Michael received his Ph.D. in computer science from UCLA in 1994.
Most Helpful Customer Reviews
DO MEEEE!!!! Mrnoob467
Moonstar here im at res 5 and how do I do those symbols? Lol thx
Do me signed RFace360
Could you do my name please? Signed skydoesminecraft
Just put your name at res 1 and look for your name at other results. And if you dont like it ask for a redo at result 1.
The basic aim of the book is well described in its first chapter. It tries to define a standard for writing distributed systems that is analogous to object oriented ideas for writing a single system. SCA builds on its predecessors; notably CORBA and DCOM from the 90s, and Java EE and .NET from the noughties. At this point, if you are a EE or .NET person, you probably agree that CORBA and DCOM were flawed. But you would probably disagree about EE or .NET itself. The book argues that those two, while better than the 90s, also have taken on increasing complexity. A multitude of standards like JDBC, JPA, JMS and EJB have flowed in the java world. While the .NET environment also have equivalents to address similar needs. Interestingly as a point of sociology, SCA also is deliberately different from how CORBA and EE arose. Those were complex standards put together by official committees. SCA was designed to change quicker, by being at its core somewhat ad hoc industry collaborations. If you are a java programmer, the flavour of the book's technical discussion is like an extended foray into the use of java interfaces. Just an analogy. But the explanation of making components that can then be used in services makes this a good one for understanding. Also, on pages 72-3 is a very succinct explanation of why EJBs never really took off, due to the performance penalties for remote calls and the complexity of the EJB code. If only the EJB books from 10 years ago had told us!