SOA for Developers
Service Oriented Architecture is a structure that requires a number of specialized employees working in positions such as Object Librarian, Configuration Management, and Information Architect. Junior developers or individuals who prefer dealing with web development, focus exclusively on the presentation tier. Such individuals are very productive, as the vast majority of the business services and rules will be available to be assembled into the UI’s. Individuals who enjoy writing code can dwell in the business rules tier, where important services and components may be developed.
More experienced developers will be able to construct enterprise wide services and components, such as authentication, encryption, and error handling. Other individuals working in development are required to focus on specific application services and components, like printing invoices, the creation of orders, and a whole lot more.
Java SOA Development
The next generation of development standards is going to focus on two main areas:
- Providing of a common model for control of relationships among services;
- Allowing developers to implement robust web services utilizing familiar Java objects.
JAX WS is a standard that is defined in Java community process that is descriptive of how Java developers may go about creating Web services. Like a lot of newer Java EE specifications, JAX WS eliminates much of the complexity that is associated with the development of web services. For instance, JAX WS provides a very simple model for the implementation of business logic, while exploding the contract as a WSDL interface via the use of annotations on the code of implementation. Through the leveraging of JAX WS, developers are then able to build portable services by utilizing skills that can be applied widely across many different products.
Java ME SOA Development
A lot of mobile applications currently necessitate the utilization of one or more applications on the server side. Such applications are not able to function – at least not fully – unless they are helped by one or several external applications. Such mobile applications hence transform into distributed applications. Java ME developers construct distributed applications quite often utilizing custom protocols that are tunneled via HTTP.
Whenever end-to-end Java is possible – meaning the endpoints of the communication path are both Java applications – then it is quite common for the applications to exchange information in the form of custom serialized Java objects. A major problem with distributed architectures is the tight coupling among the various segments of the distributed application. The utilization of custom object serialization for the purpose of data transfers is a common sufferer of this problem. While it may seem easy and convenient, programmers often fail to keep in mind that connections tend to be restricted to the particular servers that have an understanding of the protocol.
Any changes that have to be made to that protocol necessitate server reconfiguration. When code is written for extremely constrained programming environments, quite often there is little choice for the creation of such a tight coupling of server and client. As constraints to processor and memory are removed, however, the switch to a more flexible model of SOA becomes a possibility. SOA can be thought of as a style of distributed computing that allows for a loose coupling among various components belonging to an application.
In SOA model, services are provided that are independent of platforms. It is exchanged through the use of both extensible and portable formats. There are numerous ways to manage various services. Applications utilizing the services offered under a SOA are not dependent on the means that those services are implemented by.
This is comparable to the process whereby Java interfaces are utilized within an application as a means of decoupling abstractions from their implementation. Such loose coupling both allows and even encourages the utilization of services from a variety of providers.
This offers application developers a lot more flexibility in the construction of applications through combining services in novel ways. Already a marketplace has developed among service providers, with companies such as Amazon.com offering pay-as-you-go services for the storage of data. Web services tend to be employed as the foundation for Service Oriented Architecture.
They take advantage of the almost universal support available these days for HTTP as a means of creating services that are accessible on nearly any device that is connected to the Internet, whether that device be wireless or wired. Usually REST, SOAP, or some other abstraction layer on top of HTTP is utilized as a means of invoking services and the exchange of data among clients and servers.
In SOA, Java ME is especially well suited for client application development. This is because device constraints tend to be very limiting when compared with desktop situations. Thus, it is a lot harder to offload pricey operations to external systems. This is why a need arises to communicate with such systems through web services.
As it often happens, HTTP support can be visible on nearly any Java ME environment. The device’s Connected Limited Device Configuration includes it as part of the Mobile Information Device Profile as well as the Information Module Profile. The Connected Device Configuration also includes it as one of the main configuration features. HTTP support, however, is only the first step.
Usually, an XML parser will be required as a means of parsing data that has been returned by web service invocations. As opposed to HTTP, Java ME support for XML is not totally universal. Parsers are available, however, for inclusion on all Java ME environments, either through open source projects such as kXML or through the optional package J2ME Web Services Specification.
Services that are REST based are loosely defined. They require custom coding as a means of marshalling data, invoking services, and un-marshalling responses. SOAP based services, on the other hand, tend to have much more complicated semantics. SOAP based services will require support beyond XML parsing and HTTP communication.
Oracle SOA Development
Oracle Fusion Middleware combines all the key SOA standards together into a common service infrastructure. Such a service infrastructure is in turn shared throughout the entire middleware platform. This guarantees a common, interoperable basis for the deployment of the next generation of enterprise applications.
Developers can thus configure services that have been deployed upon the service infrastructure in order to leverage such standards through the use of a composite service descriptor, as has been described the Service Component Architecture standard.
This model presents an elegant mechanism for the combination of all the standards into a simple description of services as well as their relationships. As standards are considered to be the starting point for all interoperability, Web services that are constructed with Oracle Fusion Middleware tend to conform to two profiles delineated by the main industry consortium on interoperability.
One is the WS Interoperability Basic Profile 1.1, while the other is the Basic Security Profile 1.0. What is more, Oracle makes extensive use of testing frameworks that are focused solely on interoperability with major vendor platforms as well as open source web services stacks.
Oracle also participates in interoperability events that are open to the public where vendors can validate interoperability among platforms. This gives application developers a foundation upon which they may then build interoperable services that can be readily coordinated in the formation of composite applications.
Oracle Fusion Middleware is renowned for providing comprehensive infrastructures and tooling for the deployment and development of service-oriented applications that are based on J2EE applications, as well as ESB flows and BPEL processes.
Through the usage of unified Service Oriented Architecture tools that are provided in Oracle Jdeveloper, it is vital to bring services together in to a new generation of business processes and composite services. Once they are built, the services can then be deployed to an SCA based service infrastructure, which is a run time environment that renders a common bus for both network connectivity and the delivery of messages. The service infrastructure is then shared across the Fusion Middleware Platform, allowing single infrastructure to provide such services to the full product suite.
.NET SOA Development
With Visual Studio .NET, developers are now able to support dotnet objects directly through common language run time services that effectively remove coding responsibilities from the developers. Without the presence of a Service Oriented Architecture, such as the .NET framework provides, there is a lot more coding that has to be done by each developer who is working on the construction of a given system – there is even more coding at stake for the building of reusable common code for numerous systems.
This is why the utilization of a consistent, common framework for the deliverance of CLR based applications can drive a lot of developers to design services that are more reusable than the services found in the COM format. The only question that remains is to whether dotnet developers will begin to proactively design new applications in the form of flexible service oriented systems or whether service orientation in dotnet format will be merely an afterthought.
