Index:
1) Service-Oriented Architecture as a foundation for the future of the enterprise application development
2) Modularis Releases Architected-RAD Environment for .NET
3) What You Need to Know About Service-Oriented Architecture by Todd Datz
4) About Modularis
1. Service-Oriented Architecture as a foundation for the future of the enterprise.
by Jaime Marcial
Service-Oriented Architecture (SOA) is a software architecture in which all operations are encapsulated in small but independent units of functionality (services). These services are defined using a description language and have exposed interfaces that are called by services to perform business processes. These services should be platform-independent.
SOA is not Web Services. Web Services are a set of technologies (including SOAP, XML, UDDI, and others) that can provide a standard data transport and invocation mechanism. By contrast, Service-Oriented Architecture is a design paradigm that is independent of any specific technologies. So it is possible to have SOA without Web Services, and it is also possible to have Web Services without a Service-Oriented Architecture.
In other words, Service-Oriented Architecture is used to design independent building blocks that know how to perform a set of related tasks. Each block can be referenced by other blocks to provide a specific context for operation. In this way, disparate business needs can often be addressed simply by re-arranging these blocks of encapsulated functionality.
SOA is best suited for applications that sit at the core of a business, where modular services are defined and shared across different business domains.
Should you adopt a Service-Oriented Architecture in smaller development efforts?
The decision, specific to every organization, should be made by balancing the added functionality and longer life a Service-Oriented Architecture provides against the added cost and development time.
It is my opinion that the decision should not be based on the size of the project, but rather on a forecast of the future use of the functionality provided by the application. If the application implements functionality that intersects different business domains, it is a perfect candidate for a Service-Oriented Architecture.
Today, most enterprise applications are designed and built around usability. Most functionality is based on the different use cases of the application. This typically results in a monolithic application layer that provides the required supporting functionality to every interface involved.
Service-Oriented Architecture takes a different approach. It requires taking a step back and looking at the big picture instead of concentrating on just a single application. When designing an application, you should think about how it will affect other processes, manual or automatic, within your organization. Will it fully or partially replicate functionality of an existing system? Is the functionality shared across different business domains? Does the functionality have a different context in each of them?
By following this approach, you will solve your current business problems while being prepared to face any future challenges. This extends the life of your application, which translates to a better short- and long-term return on your investment.
This new level of abstraction also promotes code reuse. Given that an application was developed following industry best practices, standards, and well-defined patterns, maintenance nightmares become a thing of the past.
Next month, we will explore a practical example of how to go about designing a Service-Oriented Architecture in an environment where new development and existing applications come together to provide an Enterprise-wide solution that is built to last.
About the author
Jaime Marcial, a Senior Software Architect at Modularis, Inc., has a background in software architecture, software development methodology, data modeling, application development, and a host of other technologies. He serves as an architect, trainer and consultant at Modularis. He co-authored the Modularis Enterprise Application Development Methodology, and is one of the lead designers and developers of the Modularis Accelerator tools. Jaime can be reached at mailto:marcialj@modularis.com.
2. Modularis Releases Architected-RAD Environment for .NET
CHICAGO, IL August 10, 2004 - Modularis, Inc. today announced the official release of Modularis Accelerator 6, an Architected-Rapid Application Development (Architected-RAD) Environment for the Microsoft .NET platform.
Accelerator is the only Architected-RAD environment for the Microsoft .NET platform. By combining a proven and efficient Service-Oriented Architecture (SOA) with software automation technology, Modularis helps organizations address the fundamental shift towards service-oriented enterprise application development.
"Modularis Accelerator has increased developer productivity by a factor of ten," said John Reilly, Vice President of Software Development for Valor Systems. "With Accelerator, we will be able to get our .NET software to market faster and without needing to hire outside contractors. What's more, the quality of the software we produce will be much better because using Accelerator has enabled us to invest more time in design." Valor Systems is an early adopter of version 6 of Modularis Accelerator.
Microsoft ushered in the era of Rapid Application Development (RAD) with its 1991 release of Visual Basic. "Although RAD tools like VB provide a leap forward in productivity, the code-centric approach adopted by most RAD developers often results in short-lived, difficult-to-maintain 'spaghetti code,'" said A.J. Singh, co-founder and CEO of Modularis, "Modularis Accelerator extends Microsoft Visual Studio .NET to provide an Architected-RAD environment that resolves this problem-it effectively bakes-in a proven and efficient software architecture into the development process."
Contacts:
Gery M. Knapp, Modularis
(312) 648-1740 x208
John Reilly, Valor Systems
jreilly@valorsystems.com
3. What You Need to Know About Service-Oriented Architecture
by Todd Datz, Jan. 15, 2004 Issue of CIO Magazine (www.cio.com)
Don Buskard, senior vice president and CTO at AXA Financial, a $7.5 billion insurance and financial services company, compares his service-oriented architecture (SOA) to a system of gears: some big and slow-turning, some small and fast. And Buskard believes SOA is the right mechanism?a transmission of sorts?for an IT environment (like so many others) in which relatively ponderous data-crunching legacy systems must mesh with agile front-facing applications.
Service-oriented architecture isn't a new approach to software design. Some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, says the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces (an idea called encapsulation). But lately, SOA has been gaining traction, especially as CIOs begin to think seriously about Web services. Gartner estimates that by 2008, more than 60 percent of enterprises will use SOA as a "guiding principle" when creating mission-critical applications and processes.
But to implement an SOA, you must first understand it?and that isn't always easy. So let's begin with some simple questions and (hopefully) simple answers.
What the Heck Is an SOA?
SOAs start with services, which are groups of software components that carry out business processes, for example, verifying a credit card transaction or processing a purchase order. At its most basic, an SOA is a collection of services on a network that communicate with one another. The services are loosely coupled (meaning that an application doesn't have to know the technical details of another application in order to talk to it), have well-defined, platform-independent interfaces, and are reusable. SOA is a higher level of application development (also referred to as coarse granularity) that, by focusing on business processes and using standard interfaces, helps mask the underlying technical complexity of the IT environment. It's like translating a high school science text for your kindergarten-age daughter; you can tell her that the heart pumps blood without getting into the mitral valve and pulmonary veins.
Isn't SOA Just Corba in New Clothes?
No. SOA is an evolution from traditional tightly coupled application connections?including common object request broker architecture, or Corba?to loosely coupled ones, such as Web services. Tight coupling makes it hard for applications to adapt to changing business requirements, as each modification to one application may force developers to make changes in other connected applications. Also, object-oriented development uses a finer level of granularity?objects might be defined at the level of employee or customer order. In an SOA, a service is defined at a more abstract level, say, a business process such as generating a phone bill.
What Are the Benefits of Adopting an SOA?
SOAs make it easier to integrate the "everything but the kitchen sink" IT environments found in most companies. "That's the big value of an SOA; it works very well in heterogeneous environments," says Jason Bloomberg, a senior analyst at ZapThink, a Web services consultancy. Developers don't have to spend an inordinate amount of time writing new lines of code to connect applications. Instead, they can use standard protocols, such as Web services. And large chunks of SOA code are reusable, reducing development costs.
An SOA takes your legacy investments?your SAP, Siebel, Oracle and the like?and makes them all play nicely (and more cheaply) together.
"That's the sweet spot for SOA?leveraging your existing portfolio," says Tim Bass, president of Silk Road, an IT consultancy. You don't need to rip and replace those systems with brand-new ones. By identifying the capabilities of existing systems and leveraging them, you maximize the value of your IT investments while minimizing your risk, he says. Also, building services?for example, using simple object access protocol (SOAP) and Web services description language (WSDL)?not only smooths the internal integration process, it also lets customers and business partners share information more easily across company firewalls.
Another benefit of an SOA is that it can lead to a better dialogue between the CIO and line-of-business execs by forcing IT workers to think in terms of business?not technical?architectures. If a business wants to build a better inventory control system, for example, the operations folks can hook up with the IT architects and talk about the best way to design it based on business flows and how best to meet the needs of the business. And implementing that design, which often involves large-scale integration, becomes a less gruesome task.
For that dialogue to work, businesspeople have to think about the best ways to run their business. What processes do I need to put in place to best accommodate my customers? How can I improve my level of customer service? By exposing and sharing information across once-siloed applications, companies can extract more business performance data in real-time, improving business intelligence. There's a whole new level of responsiveness companies can exploit through a common architecture, says Dana Gardner, a senior analyst at the Yankee Group. "If there's a hurricane on the East Coast, [resulting in a] great need to move plywood from another part of the country, I can be responsive in real-time," he says. "I have information about what's going on in my business that I didn't have before." In a perfect SOA world, companies improve their ability to adapt to changing business requirements and shifting market conditions.
Finally, the benefits of easier integration and increased agility lead to greater ROI. Buskard says he's achieved a 200 percent return on his SOA investment. One of AXA Financial's most popular SOA-based services is Get Client, in which any front-end app can issue a command and, after probing around the legacy systems, come back with a complete picture of a customer's investments. Buskard says that Get Client is one example of how AXA achieves its ROI?developers design services to be generic enough that they can work with an array of front-facing systems, reducing development time and freeing developers to spend more time on business solutions. In addition, IT workers can easily incorporate new technologies into the SOA, reducing risk and expense while speeding development of new applications.
What Role Does Web Services Play in an SOA?
First, it's important to note that an SOA does not require Web services; and Web services can be deployed without an SOA. There are those, however, who believe that building an SOA using Web services is the ideal approach. Gartner's Thompson belongs to that camp. He cautions, however, that users must implement Web services properly to create an SOA. If done correctly, he notes, a Web service is little more than an SOA that uses SOAP and WSDL.
Buskard, on the other hand, has built his company's SOA without Web services, as none of his internal or external customers are asking for them at this point (though he's keeping his ear to the ground in case they do later on). Instead, he uses IBM's WebSphere MQ as a messaging and integration layer to connect legacy systems with his front-end apps. This works in tandem with Candle's PathWAI suite, which helps optimize WebSphere MQ by monitoring its performance.
Jon Johnson, chief engineer for Northrop Grumman Mission Systems of the Colorado Springs Engineering Organization, also has built an SOA, based on a publish-subscribe system (see "An SOA Glossary," left) without Web services. He's deployed Java Message Service as a messaging layer on top of a Web server and an application server, and uses the enterprise service bus from Sonic Software to help with integration and data movement. Johnson says that his services are designed like Web services, only without the Web services interface.
One of the major benefits of the SOA, he says, is that the right data gets sent to the right person or application. For example, when a user logs on using an ID, the system knows who the user is and pushes only the data?for example, maps and task lists?that the person is authorized to see.
What Are the Challenges?
Security is a big one. "It's always easier to secure a closed system than an open architecture," says Silk Road's Bass. CIOs must deal with the lack of security standards for Web services (see "Calculated Risks"). To overcome some of these security roadblocks, Bass advises that companies move slowly when setting up an SOA, focusing first on business processes that don't require a high level of security.
Trying to manage the complexity of a services configuration can be tricky as well, says Bass, and requires a good SOA governance model. For example, if you have nodes on a network that are service-oriented and 100 people are using a certain interface, how do you communicate with those users if someone decides to change the interface?
Another issue is network monitoring. "As we create the capability to orchestrate complex Net-centric business processes in a service-oriented architecture, we also create complex monitoring and auditing requirements," says Bass. For instance, when a transaction goes awry on a service-oriented network, which could involve multiple service providers, finding out what went wrong or where the transaction dropped or whether someone put bad information in the network can be a challenge. "The current Web services technical standards are only beginning to scratch the surface in making these lofty service-oriented distributed collaboration, process orchestration and monitoring goals a practical reality," Bass claims.
Finally, there's the cost issue. Building an SOA isn't cheap; reengineering your existing systems architecture is going to cost some serious money. It also requires significant human capital, including business analysts to lay out the business processes, systems architects to turn processes into specifications, software engineers to develop the new code and project managers to track it all.
Are There Any Generally Accepted Best Practices for Building an SOA?
It may sound obvious, but having a blueprint for your SOA is critical. It's very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building an SOA is to keep people?including both IT and business-side staff?focused on the architecture goals.
IT execs will also need to identify the right level of service to provide. And those services shouldn't have too fine a granularity?that defeats the goal of services, which is to function at a higher, business-process level. Too narrow a focus creates a need for more services, which increases development time. And in the worst case, too many services can flood a network. You should also employ an SOA where it will do the most good. Bass notes that quality of service needs to be taken into account when implementing SOAs. He says that a loosely coupled architecture is good for systems that don't require near-real-time responses. Pick systems where, if information doesn't get where it needs to be on time, the consequences are minor, not catastrophic. (For example, an SOA-based air-traffic control system would be a bad idea.)
Should You Be Thinking About an SOA?
Many CIOs are seriously considering SOAs, particularly as they experiment with Web services. The potential payoffs are compelling?increased agility, faster and cheaper integration, the leveraging of existing IT assets and a focus on business processes. Sure, building an SOA requires a significant investment, and there are still plenty of questions around the immature Web services market. But, at a minimum, it's a strategy worth watching.
Jan. 15, 2004 Issue of CIO Magazine
www.cio.com
4. About Modularis
Founded in 1999 and headquartered in Chicago, Illinois, Modularis, Inc. is doing
for software, what automation and robotics has done for manufacturing. Modularis
leveraged its expertise in Service-Oriented Architecture (SOA) and automation to
build Modularis Accelerator 6, an Architected-RAD environment without equal on
the Microsoft .NET platform.
Accelerator enables Modularis customers to build scalable, available, and
maintainable .NET applications at a fraction of the risk, time, and cost
typically associated with custom software development. For more information
about Modularis Accelerator, call Gery Knapp at (312) 648-1740 x208, or visit us
on the web at www.accelerating.net.
|
