Service-oriented architecture (SOA) has arrived, and with it have come a faster application development process and the ability to adapt more flexibly to changing business needs. The Gartner Group predicts that "By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture." So what is SOA? Basically, it's an IT approach in which applications rely on services available on a network such as the web to facilitate business processes. Implementing an SOA can involve developing applications that use services, making applications available as services so that other applications can use those services, or both.
To get up-to-date on the importance of SOA for Java technology developers, we met with Mark Hapner, Distinguished Engineer at Sun Microsystems, who has served as lead architect of the Java Platform, Enterprise Edition (Java EE, formerly known as J2EE), co-lead of the Enterprise JavaBeans (EJB) specification, and lead for Java Message Service (JMS). He is currently Sun's chief web services strategist. Hapner also helped create Java Business Integration (JBI) and is Sun's board member on the Web Services Interoperability Organization (WS-I).
When will a complete SOA platform be available? Or is SOA so dependent on pragmatic business considerations and unique contexts that such a notion is misguided?
It's a little like asking, "When will the web application platform be complete?" Both will evolve over time. Important core elements will come out, and other elements will be built up around those. An SOA platform has five core functions.
The first is service composition. A major portion of an SOA platform is devoted to the tools and services used to develop services as IT applications, develop compositions of these services, and govern the services architecture they form.
The second is service control. These are the tools and services an administrator uses to manage, monitor, and set policies for the set of services that run the business. It also begins to include business activity monitoring, which helps the business monitor and visualize the state of the business as reflected by the business events that occur at the service level. If you look at these two areas -- service composition and service control -- they're primarily tools-oriented in the sense that service composition covers the developer role, while service control covers the operations role. Both require a rich set of tools to do their work.
The third area is the runtime infrastructure that hosts the business logic of production services. Sun calls this services infrastructure the composite application platform. It consists of engines (also called containers) that implement the runtime support for each of the several service technologies that a service may depend on, such as Java EE, BPEL (Business Process Execution Language), SQL, Business Rules, XSLT (Extensible Stylesheet Language Transformation), and so on -- everything that it takes to execute the variety of ways that a service may implement its business logic. In addition, it contains all of the application-specific connectors required to access existing applications that have not as yet been exposed as SOA services.
The fourth function of an SOA platform is service delivery. This is the infrastructure that supports a service's interaction with other services. This includes all of the protocol support, the web services, the security infrastructure, and the policy execution infrastructure necessary for the service to interact with its peer services. It can be thought of as the glue that holds an SOA platform together. Without it, SOA cannot exist. The fact that in an SOA architecture, service delivery has been promoted to first-class status, rather than being treated as just additional plumbing, mirrors the fact that web servers have attained this role for web applications. It is the infrastructure whose role it is to realize the service interface as an element separate from the business logic that processes the messages that flow through it. It mediates the use of a service by other services and access channels (web apps, mobile clients, RFID, and other applications that act as SOA clients).
The last core SOA function is service access. This covers the applications used to access services such as web sites, portals, mobile clients, RFID applications, and so on. These provide the access channels by which the wider world of users connects to an SOA.
The Global Computing Model
You've said, "We have now entered the phase where the computing model is a global model, and our job as vendors is to support that global computing model, and support our customers' success in using it." What should developers understand about global computing?
We must deliver global technology, whether it's a protocol or a web implementation technology or a web site implementation technology. It must have a practical, scalable, global capability to be a core computing building block. Technologies that only work in small environments and that are vendor-specific or vendor-proprietary have become far less important. Sometimes a smaller environment can sustain an individual technology that you might, for example, only use in a motor vehicle control system. So not every technology needs to be part of the global computing model (although the auto is going global as we speak). But for most services and SOA, it makes sense for developers to use interoperable technologies that are proven to work globally.
Sun's goal is to deliver the best implementations of global technologies, such as elements in the web services stack and BPEL, which is being standardized by an OASIS technical committee.
How important is it for an SOA platform to maximize both its internal and external use of standards?
We can draw on the experience we've had with web applications. Technologies that are broadly accepted and open have the most value, even if they are somewhat simpler or less efficient than a particular individual vendor's technology. SOA's core vision is a global computing model that eliminates interoperability roadblocks. But there's a danger: Many of the currently promoted technical standards don't provide interoperability out of the box. They need to be highly profiled. As in web sites, interoperability must be our overriding goal, rather than prematurely optimizing or customizing our technologies. If we don't do this, we run the risk of ending up with the same integration problems we set out to avoid.
The Danger of Waiting for Standards
Is there a danger that developers will wait too long for standards to become established before attempting SOA?
Creating web sites showed us what could be done with very minimal standards. Rather than waiting for any one vendor's highly complex architecture, I'd suggest starting with the minimal functionality that's needed, and as applications mature, be conservative in introducing new infrastructure and protocols.
Go ahead and use the technologies in small projects and learn what you need to get interoperability. The real issue is not the protocols but rather the application-level value they enable. Most web developers don't obsess about the details of HTTP -- they just use it to deliver the function of their web site.
A Web Site for Machines
What are the greatest challenges in developing SOA architecture? Is it true, as some have claimed, that SOA requires a shift to a different computing paradigm and a greater appreciation of the needs of business?
SOA requires that a service be a composable, universally accessible function, whether as a web site or as an application service. One way to think about a service is as a web site for machines. Here's the tricky part: How do you do this in a practical way that provides value to a wide enough range of customers to make it worthwhile? The focus is on how you structure the semantics, the function of that service. How do you design effective messages and the composition of those messages so that they deliver the function in the simplest, most modeless way? The real challenge is to figure out how to design these services so that they're rich enough to be broadly usable but simple enough to be practical for the broader community to understand and access.
XML and SOA -- Love and Marriage
Is XML at the core of SOA?
Yes, XML shows up at practically every level of the architecture -- the metadata, the protocol, and the business messages themselves. It shows up in the applications as a way of capturing the function of the application as BPEL and as XSLT. One challenge is at the application level. Though XML has the potential to simplify composition, it requires a lot of know-how to design application messages properly, to use the appropriate business-level vocabulary in those messages, and to construct the messages so they're properly linked together to accomplish a business task.
The service interface is the core design artifact of SOA, and that interface captures the message and conversation design of a service. Unfortunately, the metadata that we have today falls a little short in capturing the conversation semantics, but at least with RELAX NG and XML Schema, we are able to do a reasonable job in describing the structure and syntax of its messages. WSDL (Web Services Description Language) adds a description of the MEP (message exchange patterns) that a service uses to exchange messages with its peers.
T. N. Subramaniam, whom I interviewed about RouteOne's SOA solution, said, "SOA requires people to adopt a new paradigm in which applications are a collection of both external and internal services." Any comment?
From a zoomed-out perspective, an application offers input and output pins for the web of services it interacts with. Input pins are, in effect, the services that it offers, and output pins are the services that it relies on. Zooming back in on the application, it is constructed more or less in the same way. It is very effective to structure the internal architecture of the service as a composition of coarse-grained message-processing components.
Within a service, its message-processing elements may be a mixture of business logic coded as an EJB or a BPEL script to implement a service composition or an XSLT script for data transformation. The application, in effect, becomes a microcosm of the web, in that it's using many of the same composition techniques internally that the network is using externally.
So, yes, to answer your question, I agree with this way of looking at SOA applications. In fact, the Java Business Integration (JBI) technology is based on this architecture. Its objective is to support this two-level view of composition, at the web layer and within the application.
Subramaniam has also predicted that JBI will do for the integration space what Java EE did for the transaction space.
Composite applications are a strategy for application development that will become a core element of SOA. And the purpose of JBI is to make sure that the Java platform has the infrastructure needed to support this model of application development. By providing formal support for this model in the Java platform, we're ensuring that the Java platform will continue to be the core infrastructure for application development. JBI will be extremely important in allowing the Java community to deliver the composite application infrastructure that developers need to effectively implement SOA services.
The Sun Java Enterprise System (Java ES)
The Sun Java Enterprise System (Java ES) offers many of the SOA platform services that IT will require, but what doesn't it offer? And when will a complete, off-the-rack SOA platform be available?
Every organization will make their own decisions about how to build their SOA platform. For some, the highest priority might be putting a governance structure in place. Others might make sure that they have appropriate protocol support and will incrementally build services based on that. Since most organizations already have complex platforms in place, each organization will have to decide how to incrementally populate their SOA platform with tools, services, and infrastructure. The issue is how they start aligning these with the conceptual model of an SOA platform that I described earlier. At each step, they should put in place only those parts that are required to accomplish the SOA task at hand. This is the same way that web infrastructures were built out. Smart organizations had a general vision that they pragmatically populated. The same holds true for SOA because it is just another application of global computing applied to solving application-to-application integration problems.
From a Java ES perspective, we offer a number of those services today and some core protocol support for web services in the Java EE platform. We have production-quality directory support and SOA registry-repository support, plus a number of services that support identity and access control. What's really important to understand is that no one company has fully defined the set of infrastructure services that are needed to fully complete an SOA platform, because the whole platform concept is still in its infancy. Numerous services are being proposed, but the value that each provides is still being debated as our experience with them grows.
Here's the key point: If you are going to invest in a platform service, it should be one that is core to current productivity and collaboration. This could be identity, repository, access control -- whatever you see as the key to effective collaboration within your platform, because the essence of SOA and its core value is the collaboration it enables.
Is it important that an SOA platform's services implement global computing standards?
Yes. For instance, if an SOA platform provides an identity service, it's important to align with the SAML (Security Assertion Markup Language) standards because that's one of the core technologies that underlies global identity. It's just an example, but an important one, I think. As you acquire new applications, either bought or developed by you, they must collaborate with the identity service. You've got to choose vendors who are aligning their service implementations with the global computing model.
And second, I recommend steering clear of solutions that attempt to work around the necessity of collaboration by adding a new layer on top of everything, injecting agents into applications, or some other scheme. Only through loosely coupled collaboration do you get the true value of SOA. The layered solution can provide some breathing room in local environments, but it ultimately does not scale. That is, layered services by definition can't be global.
SOA and Web Services
What's the distinction between SOA and web services? Are web services simply one direction that SOA can take?
Again, the web site analogy applies here. For instance, you might ask, "Well, what's the distinction between HTTP and Amazon?" Web services are simply the protocol layer, important because they're a key element of interoperability, but they are only a path to the value a service offers.
You shouldn't have to obsess over the content of the SOAP header any more than you should obsess over the content of the TCP/IP header. Web services is basically the plumbing, and SOA is the functionality your services collaboratively deliver.
Why shouldn't developers believe that all this talk about SOA is just hype?
SOA is simply the promise of carrying over the collaboration enabled by web applications to the collaboration of business functions. It will happen because global computing will affect enterprise integration just like it affected client-server computing. While the details may vary from what we see now, nothing can stop this next wave of global computing.
Advice to Developers
Any basic advice to developers and IT people who are developing an SOA platform strategy?
Be conservative and begin with an overall strategy. Instead of trying to build out the entire infrastructure before you complete the first application, set up the infrastructure as it's required. Within your broad SOA strategy, you can be very pragmatic about individual elements to get maximum business value out of each.
What should Java technology developers understand about SOA that they might not currently understand?
The core thing to understand is that "It's the message, stupid." The fundamental building block of global computing is the message and message exchange. Message-based computing is a different model that many enterprise developers are not too familiar with. It will take some time for them to learn how to effectively design and implement message-based services.
2017年04月08日 1.69MB 下载
2017年03月17日 5.34MB 下载
2015年08月24日 5.26MB 下载
2011年05月03日 287KB 下载