Build and deploy your own service-oriented application using open-source products PHP and ActiveBPEL engine, as described in this easy-to-follow tutorial guide. This practical book explains in extensive detail how to build Web Services with PHP and then utilize them within WS-BPEL orchestrations deployed to the ActiveBPEL engine. This book is suitable for anyone who wants to start building SOA applications using powerful tools available free of charge. It also will be useful for PHP developers willing to move towards Service-Oriented Architecture (SOA). Readers need only a basic knowledge of SOA, BPEL, and Web Services; even a total beginner will be able to follow the examples, provided the required software components are installed on his or her computer. More experienced readers might use this book as a reference, focusing only on the chapters of interest.
SOA and WS-BPEL
and over one million other books are available for Amazon Kindle.
Learn more
| |||||||||||||||
Book Description
Editorial Reviews
About the Author
Yuli Vasiliev is a software developer, freelance author, and consultant currently specializing in open-source development, Oracle technologies, and service-oriented architecture (SOA). He has over 10 years of software development experience as well as several years of technical writing experience. He wrote a series of technical articles for Oracle Technology Network (OTN) and Oracle Magazine.
Product Details
Would you like to update product info or give feedback on images?
|
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
15 of 15 people found the following review helpful:
4.0 out of 5 stars
Book Review: "SOA and WS-BPEL" by Yuli Vasiliev,
By
This review is from: SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL (Paperback)
What I like about this book:
The choice of PHP as an implementation language: This is a refreshing reminder that SOA is about hiding service implementation details from service consumers. The implementation language doesn't always have to be Java or C#. What matters is what the service consumer sees (i.e., SOAP). There is however, a downside with PHP, which I'll cover in a moment. The use of Open Source technologies: I believe that Open Source is the way of the future, and the use of Apache/PHP, Tomcat and ActiveBPEL to illustrate SOA concepts feels just right. Besides, readers can readily try out the examples in the book without having to buy expensive commercial software. Copious examples: This is not a theoretical book, and there is plenty here for the reader to try out for themselves. Every concept that the author deals with is represented in code. [I can't comment on how complete or correct the examples are and whether they work, because I haven't tried them out yet.] Lots of diagrams: Pictures are really worth thousands of words, and there are diagrams sprinkled liberally throughout the book to illustrate almost every concept discussed. I thought they were quite decent. Emphasis on data: One of my pet peeves with many people's approach to SOA is their relative neglect of the Data Interchange view of service interactions. SOAP-based web services is about exchanging XML documents that represent some structured data relating to the operation being performed. There is a lot of design that needs to go into these XML documents. Thankfully, the author spends a fair amount of time showing how to design the data payload of messages with XML schema and converting data into XML format (but a nit about that bit later!) I also liked the treatment of the data within the contract (importing the schema file into the WSDL file instead of defining the schema in place). Introduction to WS-Security and to Qualities of Service (QoS): The book has a section on implementing secure messaging using WS-Security, and also makes the point that virtually all the WS-* specifications use SOAP headers to implement functionality. There's not too much here, but enough to get the developer to understand the WS-* approach. View of a process as a service in its turn: One of the value propositions of SOA is its ability to exhibit a "flat" landscape of services, regardless of how they were implemented. From a service consumer's point of view, it doesn't matter if a service was purpose-built in a programming language (e.g., PHP) or stitched together out of other services (using BPEL). Services of both types should look the same. The book shows how composite services can also be exposed as services in their turn, with the appropriate WSDL sections highlighted. WS-BPEL treatment at the right level of detail: I thought the level of discussion and the examples of WS-BPEL were just right for a beginner. There is enough detail to be meaningful, but not so much as to overwhelm. What I don't understand or don't like in the book: The title: SOA and WS-BPEL are like fruit and oranges, not even apples and oranges. The first is an architectural approach; the second is a language used to implement processes. Considering that the book deals with building standalone web services in the first part, then composing them into processes in the second, perhaps it should have been called "SOAP and WS-BPEL" or "SOA: SOAP and WS-BPEL". The unquestioning acceptance of the RPC view of Web Services: I have religious feelings about RPC. It is the devil's spawn. Many of the REST camp's arguments about SOAP are actually directed against SOAP-RPC. The modern view of SOAP-based Web Services is based on messaging. Messaging, not RPC. What's the difference, and why is this important? RPC is architecturally dishonest. It is impossible to make a remote object behave like a local one, and I don't mean the effect of network latency. A reference to a local object that is passed to an application carries with it the promise that any change made by the application using the reference will change the object. But with RPC, what is passed to the application is not a reference to the object, but a reference to a copy of the object. This is not an insignificant difference. When the application makes a modification using the reference, the local copy is changed, not the remote object. But the application thinks the actual object has been changed. That's what is so dishonest about it. Messaging turns this essentially hopeless exercise around. It makes local objects look remote, by always passing copies around, even if the actual object is accessible by a reference. The application is under no illusion. It knows that in order to make a change to the real object, it is not enough to make a change to the copy. Either the copy must be passed back to be synchronised in some sense with the original, or an independent operation to pass a Data Transfer Object is required. This is architecturally honest and clean. What it may lose in efficiency in some corner cases (local access), it more than regains in terms of robustness, flexibility and scalability. That's what SOAP messaging brings to the table. SOAP-RPC is evil and should have nothing to do with a book on modern Web Services. It's a pity the author actually mentioned RPC by name when introducing SOAP messaging, because the actual examples do not assume RPC. In this context, the use of PHP has a downside, as I indicated earlier. PHP is heavily tied to HTTP and by extension, to synchronous request/response semantics. SOAP-based Web Services technology does not inherently have this constraint and can work with asynchronous transports as well. The book could have illustrated this effectively using a message queue example. There are tools such as PHPMQ and Mantaray that make this possible. Automatic data transformation to and from XML: This is another of my pet peeves. The service contract (of which the XML document forms a part) is a First Class Entity. So are the classes that make up the internal Domain Model. How can one ever be generated from the other using a tool? Code generation is an example of tight coupling, and if two First Class Entities are tightly coupled, then at least one of them is not a First Class Entity. QED. I'm not sure if there is an equivalent to TopLink or JiBX in the PHP world, but such a mapping tool is what is required to transform data between the PHP and XML worlds. To be fair, this book is not alone in propagating the code generation approach. Virtually the entire Java Web Services industry is consumed by JAXB disease. Data-centric Web Services - Actually, I didn't understand the point of this as a separate topic. It's a special case of service implementation. In fact, I have a totally different view of Data-Centric Web Services. I call them REST. No high-level view of process as an aspect of the business: For a book that purports to be on SOA, the treatment of composite services and processes is surprisingly low-level and technology-oriented. There should have been an introduction that focused on business processes and their decomposition into services. In fact, SOA best practice is all about business process modelling and re-engineering. That's how architects and business analysts determine the services that are required and their granularity. Proceeding bottom-up from services and composing them into processes, as the book seems to suggest is the way to do SOA, is ingenuous. Anaemic index: The index of the book doesn't list many of the things discussed inside. I tried going back a couple of times to look up something I had seen earlier, but the index was of no help. Other comments: ActiveBPEL Designer is not an Open Source product, merely free. This isn't the fault of the author. It's just something I'm personally sad about. I haven't yet found a truly Open Source BPEL designer that is powerful and friendly, and generates full-featured BPEL. Overall comments: Actually, notwithstanding the negative comments I made (I'm a nitpicker, as my wife will attest), this is a pretty decent book on Web Services (SOAP and WS-BPEL). It's got enough low-level detail to help developers get their hands dirty and understand the technology by actually building services and processes. The choice of PHP could turn out to be a masterstroke by reaching beyond Java or C# developers and appealing to the vastly more populous LAMP community. Time will tell. I thought the book was a bit light on architectural insight, but maybe it's for the best. For a developer audience, such discussion might just cause eyes to glaze over.
5 of 5 people found the following review helpful:
4.0 out of 5 stars
explains BPEL,
By
This review is from: SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL (Paperback)
As SOA gets more usage in building distributed applications, it turns out that you need WS-BPEL. This ungainly acronym refers to a specialised programming language that is written in XML. It defines a way to write precise computational instructions or constraints that can be passed from one machine to another. Where both use SOA and BPEL. So the book goes over the syntax of BPEL. Treat it, if you like, as the pragmatic successor to JMX. The latter was touted around 2001 as a way of doing distributed java management. But it never lived up to its promises. While BPEL is not restricted to what type of language on a web server that parses and executes a BPEL message. Now the book does give examples in PHP for writing code. Since [I'm guessing] PHP is now quite popular in web applications.
There are also examples of how to tie the back end of a web server into an existing SQL database. Using MySQL and Oracle. One thing is that if you rise about the low level details in the book, then BPEL can be an awkward language to write in. The verbosity of general XML syntax contributes to this. But also that things can seem so clumsy compared to conventional procedural languages like C++ and Java. It is still not easy to navigate thru and design the various components of distributed web systems. However, and realistically, BPEL is what we have to currently work with, and the book does a good job explaining it.
5 of 5 people found the following review helpful:
4.0 out of 5 stars
A worthwhile book PHP developers or those wanting to learn ActiveBPEL,
By
This review is from: SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL (Paperback)
I recently read a new Packt book titled "SOA and WS-BPEL: Composing Service-Oriented Solutions with PHP and ActiveBPEL" by Yuli Vasiliev. I've used ActiveBPEL in the past, and there certainly is a learning curve involved in learning BPEL. However, Yuli does an excellent job of explaining both the fundamentals of BPEL, and more advanced BPEL topics such as parallel vs. sequential processing. The use of a ongoing case study walks the user logically through the learning process.
The first section of the book, which I found particularly useful given my lack of PHP experience, primarily focuses on how to consume and build SOAP web services with PHP. Using PHP with SOAP doesn't seem as straightforward as it should be, but Yuli does a good job at describing the process and best practices. The remaining sections cover BPEL, and ActiveBPEL's implementation of them. The book is fairly brief in size (280 pages), but covers a lot of material in an effective fashion. I would recommend it to anyone interested in using PHP with SOAP and/or ActiveBPEL (the BPEL portions are beneficial even if you are not a PHP developer). jeff
Share your thoughts with other customers: Create your own review
|
|
Inside This Book
(learn more)
Browse Sample Pages:
Front Cover | Table of Contents | First Pages | Index | Back Cover | Surprise Me!
Front Cover | Table of Contents | First Pages | Index | Back Cover | Surprise Me!
What Other Items Do Customers Buy After Viewing This Item?
Tags Customers Associate with This Product(What's this?)Click on a tag to find related items, discussions, and people.
|
Customer Discussions
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|
