Contents
Service-oriented architecture (SOA) -- especially web services-based SOA -- has been the talk of the IT community. It's almost impossible to discuss corporate technology plans or strategies without discussing SOA. That's because many IT professionals see SOA as a way to speed up the application development process. They also see in SOA a way to become more agile and more adaptable in responding to changing business needs. A previous article introduced SOA and web services concepts, and described the basic technologies and tools available to implement a web services-based SOA. With these technologies and tools, companies are already starting to build applications based on an SOA approach. For example, RouteOne LLC, a credit aggregation management company for the automobile industry, implemented a web services-based SOA project that resulted in dramatically streamlining and speeding up a number of vehicle financing software applications for car dealerships. You can read more about this in The Next Big Thing: Service-Oriented Architecture (SOA) Takes a New Route. Clearly, the basic underpinning required to implement a web services-based SOA is available. But companies are also looking for enhanced capabilities that will help them not only more easily create and use web services, but also help them manage and secure web services within an SOA. The good news is that some of these enhanced capabilities are beginning to emerge as new or enhanced technologies, and they're starting to be supported in infrastructure software and tools. Sun is a leading software provider in this area, with a well-defined initiative to enable and simplify SOA. As part of this initiative, SOA-specific features are being phased into new releases of Sun Java Enterprise System, Sun Java Studio Enterprise, and other Sun products.
The enhanced capabilities include the following:
This article introduces you to the first three of these enhanced capabilities and the emerging technologies, tools, and infrastructure software from Sun that provide them. The article also points to places where you can get more information about these topics. Table 1 at the end of this article briefly summarizes the other enhanced capabilities. Future articles in this series will provide more detail about these additional capabilities. Registry/Repository
Your enterprise starts implementing SOA projects. You start making existing applications available as web services, and you also create new web services. You start building applications that use these web services. You might also want to use web services that are outside of your organization, perhaps web services that your business partners offer. How do you find the web services you need outside of your organization? How do other organizations find your web services? How do you or anyone else know how to access the web services they find? The answer is a service registry. Service registries are a standard part of SOA. The initial service registry implementations typically conformed to the Universal Description, Discovery, and Integration (UDDI) standard developed by the Organization for the Advancement of Structured Information Standards (OASIS). In essence, a UDDI registry is a set of yellow pages for web services. Like the yellow pages business directory, a UDDI registry entry provides information about services -- in this case, web services. A UDDI registry entry provides information such as the service's name, a brief description of what the service does, and an address where the service can be accessed. It also points to a Web Service Definition Language (WSDL) file that describes the interface to the service. UDDI registries work well as a way of advertising and finding services. But many SOA projects, especially those that involve collaboration between different organizations such as business partners, require registries that are more comprehensive than UDDI registries. They need a way to share not only the kind of basic information that's in a UDDI registry, but also information such as business processes and security policies. That is where the ebXML Registry Standard comes into play. ebXML is a comprehensive business-to-business framework for electronically-based business collaboration. The framework was developed as part of an initiative that combined work by OASIS and the United Nations/ECE agency, CEFACT. A key part of the framework is the ebXML Registry standard. The standard provides a registry for publishing and discovering services, as well as a tightly coupled repository that holds artifacts related to the services. This allows businesses to publish and discover services and to share additional information about those services with their collaborating partners (see Figure 1). Although the artifacts can include any content, in a business collaboration scenario, the content is likely to include things such as business processes as described in Business Process Execution Language (BPEL) files, security policies, XML schemas, Web Services Description Language (WSDL) files, and XSL Transformation (XSLT) stylesheets. The need for an integrated registry/repository becomes more pronounced as companies get more heavily involved in SOA. As they implement more SOA projects and as the deployments become more complex, companies are finding that a registry is not enough to publish and discover the information needed about services. The contents of a registry and an associated WSDL file provide a base of information about a service, but often other information is needed, information stored in artifacts outside of the registry. For example, if a service is a composite of services that needs to be orchestrated in a way that mirrors a business process, it's important to know what that process is. That type of information is often provided in a BPEL file. Or if a service is accessible to portals, it's important to know how the service can be used by a portal. That type of information is provided in a Web Services for Remote Portlets (WSRP) description. (See the Portal Access to Web Services section for more on portals and SOA.) BPEL files and WSRP portlet descriptions are some of the types of artifacts that can be stored in a repository within an integrated registry/repository that conforms to the ebXML Registry Standard. Beyond the need for more fully capturing information about a service, an integrated registry/repository gives companies a central point of control for an SOA. Companies need a way to track and manage services and related service metadata and artifacts in a way that's consistent with company policies and rules. For example, a company policy might require that all service bindings must be SOAP bindings and that only document style can be used for service communication. Because it holds both the metadata and artifacts for a service, an integrated registry/repository makes it easier for companies to validate that all WSDL files specify information that conforms to that policy. This management of services in conformance to company policies and rules is often termed SOA governance. What's New?
What's new and significant in this area is the latest version of the ebXML Registry Standard, ebXML Registry 3.0, and a new registry/repository, the Sun Service Registry, that supports the new level of the ebXML Registry Standard. The Service Registry also supports the newest level of the UDDI standard, UDDI 3.0. The Service Registry is integrated into Java Enterprise System 2005Q4 (hereafter, this article will refer to Java Enterprise System 2005Q4 as Java ES Release 4). Sun Java Application Server 8.1, which is also integrated into Java ES Release 4, provides a default container for the Service Registry. By supporting ebXML Registry 3.0, the Service Registry provides a centralized registry and tightly coupled repository. This allows companies to register their services, and to store and manage metadata and artifacts associated with those services, such as BPEL files, security policies, XML schemas, WSDL files, and WSRP remote portlet descriptions. In addition to providing for a combined registry/repository, ebXML Registry 3.0 adds a federation feature. This enables multiple registry/repositories to logically join together so that they appear as one virtual registry/repository. Each registry/repository in the federation is managed by its owning organization, but the entire federation is accessible as one registry/repository. This allows businesses to do federated discovery across registries. In other words, a business can use a single ebXML or UDDI query to discover services and related metadata and artifacts in the Service Registry as well as in other registries in the federation. Federation underscores the importance of having a registry/repository that conforms to an open standard such as ebXML Registry. Conformance to that standard enables the seamless integration with local control associated with federation. Beyond its support for registry and discovery, the Service Registry also has some important SOA governance features that enable a company to specify and enforce policies that regulate the content and use of services, service metadata, and artifacts. For example, the Service Registry includes security features that control access to artifacts based on user roles, as well as features for validating and organizing artifact content. Why Is This Important?
The Service Registry is not only a registry solution, it's also a cornerstone of SOA governance. It gives companies a registry/repository for publishing and discovering needed information about services, that is, metadata and related artifacts (in fact, supporting federated discovery). Just as impotantly, it gives companies a centralized way of tracking and managing its services and related content based on things like life-cycle stage and organization policies. For More Information
See the Sun Service Registry. Federated Identity
Services in a network can be almost anywhere -- whether in different departments within a company, in different companies, or in different countries. Each can have its own safeguards or lack of them. In such a network, the opportunity to disclose sensitive information to the wrong people is heightened. Thus, maintaining security in an SOA, which brings together services in a widespread and networked way, is vital. Enterprises that implement an SOA are demanding end-to-end security, where the entire chain -- from service requester to service provider and any intermediaries -- are secured. Unfortunately, because different departments and organizations tend to implement security mechanisms in their own unique way, providing end-to-end security can be extremely complex. One aspect of providing security is authenticating identity: ensuring that the requester of a web service -- whether a person or a piece of software such as another web service -- is who he (or she or it) says he is. After the requester's identity is established, the access control system in place for the service must determine whether the requester is authorized to use the service. A typical way to authenticate identity is to have the requester log in with a user ID and password. This requires the requester to log in for each unique service. Although this might be reasonable for a small number of services, it can quickly become unworkable for a larger set of services, particularly if each has different rules regarding login. This has stimulated the need to implement a single sign-on approach and federated identity. In a single-sign on approach, the requester logs in only once. Different services in an organization can then use that login information to authenticate the requester's identity. Based on that information and related information such as a requester's job role, the requester does (or does not) gain access to the service.
Federated identity extends access control and the single sign-on approach across Domain Name System (DNS) domains so that different companies (such as business partners) in different and autonomous domains can handle authentication across those domains in a trusted way. In other words, Partner B trusts Partner A to authenticate a requester in Partner A's domain and to attest that the requester is authorized to access the services in Partner B's domain. This trusted relationship requires that the participants have established an agreement to enable such a relationship. Two cornerstones of federated identity are the Security Assertion Markup Language (SAML) and the Liberty Alliance Project. SAML is an XML-based standard developed by OASIS for exchanging assertions. An assertion is an XML construct that can contain statements about authentication, authorization, and attributes related to a subject, where a subject is either a person or a computer. An authentication assertion validates the subject's identity. An authorization assertion specifies what the subject is allowed to do at a particular site. An attribute assertion contains specific information about the subject. SAML also identifies profiles that specify the mechanisms for exchange of assertions and the roles that interact during the exchange. The Liberty Alliance Project is an effort by a consortium of over 170 organizations to address issues related to identity and identity based-web services. A major goal of the Liberty Alliance is to come up with a set of open standards for federated identity management. And so, the alliance developed Liberty specifications for federated identity. The initial level of the specifications (known as Phase 1) built on SAML and extended it. One of key elements of the Phase 1 specifications is the Identity Federation Framework (ID-FF), which enables single sign-on across autonomous domains, and allows for account linking between partners with established trust relationships. Phase 2 of the Liberty specifications added the Identity Web Services Framework (ID-WSF) and Identity Services Interface Specifications (ID-SIS), which together provide for adding web services to a federated identity environment. These specifications allow users to link identity information and credentials (such as user name and password) across federated domains. In an SOA context this allows a service requester that has an identity in two domains to authenticate in only one domain and then use its associated credentials to access a service in the other domain without having to reauthenticate. What's New?
SAML 2.0 was recently approved as an OASIS Standard. An extension of version 1.1 of SAML, it now incorporates ID-FF. This is an important first step towards the convergence of the SAML and Liberty Alliance standards for federated identity. Also, a new specification, Java Authentication Service Provider Interface for Containers (JSR 196) is making its way through the Java Community Process. It defines a standard service provider interface for authentication service providers so that their authentication modules can be integrated into a Java Platform, Enterprise Edition (Java EE, formerly known as J2EE) container in a standard way. Implementation of this specification will insulate developers from the mechanics of ID-WSF. Sun Java System Access Manager, an important component of the Java Enterprise System, has long supported both SAML 1.1 and the Liberty Alliance Project standards (ID-FF 1.2, ID-WSF 1.0, and ID-SIS 1.0) for federated identity (in fact, it was the first implementation of this functionality). The newest release of Access Manager (7.0) is tightly integrated into Java ES Release 4. Support for federated identity is also provided by Sun Java System Federation Manager, a low-cost solution for federated services. Java System Federation Manager is currently available as an early access release. Why Is This Important?
As this article mentioned previously, support for federated identity through SAML and the Project Liberty
specifications allows users to link identity information and credentials across federated domains. Not only does this permit a user to access services in another domain without having to reauthenticate every time the request crosses a domain, but it does it without any unnecessary divulging of personal information. This ability to cross domains without the need to reauthenticate -- but with appropriate privacy safeguards -- is crucial for building effective implementations of SOA.
For More Information
See Federated Identity, Access Control, and Single Sign-On Resources. Portal Access to Web Services
So far this article has covered what's emerging to aid in managing an SOA, but what about features that simplify using services in an SOA environment, particularly the delivery and access --what some call consuming -- of those services by end users? What about features that simplify bringing together a variety of services for use? Actually, some important things have been happening there too. One important advance is the increasing use of portals as a means of consuming services in an SOA. Notice that in the CMT Chips scenario, the user accesses the CMT chips web service through a company portal. A portal is designed to aggregate and present information from different applications and content sources in a personalized and secure way. It can do so through almost any access mechanism, including mobile devices. For example, a company portal might present a web page that brings together applications of value to its employees, such as a company news feed, a company telephone directory, a directory of company services, and human resources applications such as a vacation scheduler and benefits planner (see Figure 3). As shown in the CMT Chips example, portals can also be a platform for exchanging information between business partners such as a customer and suppliers. Two important characteristics of a portal are that the origin of the data that it presents can be anywhere, and that the portal personalizes the presentation of the information for the user. In other words, two users having different roles in a company might see very different views of the same portal. This customization is handled by the portal aggregation and personalization framework, and it is also handled at the portlet level. A portlet is a fragment of a portal. More specifically, it's a component that renders a markup fragment that represents an application or content view that a portal can display in aggregation with other such views. Typically the output of multiple portlets are combined to produce the portal desktop display. Creating and managing portal sites and their portlets are portal server products such as the Sun Java System Portal Server. Over the past few years there has been work done to standardize portal interfaces so that portlets developed for one portal server can be deployed onto other portal server products. That standardization effort produced the Java Portlet Specification (JSR 168), which defines the portlet API for writing industry-standard pluggable user interface components. JSR 168 is a specification for creating portlets that can be deployed locally onto a portal for aggregation, that is, where the portlet and the portal are in the same environment. Complementing JSR 168 is the Web Services for Remote Portlets (WSRP) specification, an OASIS standard that specifies a protocol and interfaces for enabling remote portlets. A remote portlet is a portlet that's deployed in a different environment than the portal that actually uses it. WSRP specifies a standard way for local portlets to be exposed through web services so that they can be consumed by other portals. What's New?
Since their inception, portals have been natural consumers of services within an SOA type of approach. However, now with the introduction of technologies such as WSRP, portals are starting to evolve towards a more comprehensive services-based orientation. Companies are starting to use portals to aggregate information through web services. The Java System Portal Server provides support for both JSR 168 and WSRP, and it was among the first industry products to support these two standards. The Java System Portal Server can act both as a WSRP consumer (a consumer of remote portlets), and as a WSRP producer (a provider of remote portlets). This means that a remote portlet can be used by a portal managed by the Java System Portal
Server, or that a local portlet in a portal managed by the Java System Portal Server can be made available for use remotely by another portal.
It's important to note that WSRP enablement is built into the Java System Portal Server, so that once a JSR 168-conforming portlet is developed and deployed in the Java System Portal Server, no additional programming needs to be done to make it remotely available. Neither is any programming required to make a portal consume remote portlets. This makes portals managed by the Java System Portal Server particularly attractive platforms for SOA. The Java System Portal Server also provides built-in support for consuming data-oriented web services by automatically generating user interfaces that allow the end user to interact with those services. This allows the consumption of services that are not inherently or natively visual.
Also emerging are tools to simplify building portlets. For example, Sun Java Studio Creator 2, which is now available as an early access release, provides a visual way to create and design portlets. Portlets that are created using Java Studio Creator 2 and deployed to the Java System Portal Server can be automatically enabled as a remote portlets. This makes Java Studio Creator 2 an excellent tool for building portlets that interface with web services. For more information about creating portlets with Java Studio Creator 2, see Creating Portlets in Sun Java Studio Creator.
There are also intersections between the new Service Registry and the emerging use of portals for SOA. Before a portal that acts as a WSRP consumer can access a remote portlet, it needs to find the producer's WSDL. That WSDL, as well as other artifacts related to the producer, can be registered by the producer in the Service Registry and made available for discovery by the consumer. Upcoming versions of the Java System Portal Server will provide additional support for publishing, managing, and discovering WSRP producer and remote portlet descriptions in the Service Registry. Why Is This Important?
Leveraging web services through portals by means of the Java Portlet and WSRP standards gives companies a relatively easy way to begin implementing an SOA. And the built-in support for the Java Portlet API and WSRP in Java System Portal Server makes implementing a portal-based SOA even easier. Beyond that, portal support for the Java Portlet and WSRP standards, allows companies to easily create and offer SOA-style services to other parties. These other parties can combine several of these visual services from diverse sources to form the visual equivalent of composite applications. This approach delivers entire services to the other party so that the services can be conveniently consumed and used without any programming effort. For these reasons, a portal-based SOA -- particularly one managed by Java System Portal Server -- is a good initial SOA implementation project for a company. For More Information
See Portal University. Additional Capabilities
Other enhanced capabilities are emerging in support of SOA. Table 1 summarizes what's new regarding these new capabilities. Future articles in this series will cover these emerging capabilities in more depth.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
Painless SOA
