Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sirius Update SUG 2004 Gary Gregory.

Similar presentations

Presentation on theme: "Sirius Update SUG 2004 Gary Gregory."— Presentation transcript:

1 Sirius Update SUG 2004 Gary Gregory

2 Agenda Welcome Some questions for the audience
schedule "tuning" Some questions for the audience ok to ditch 3480 drives? documentation Overview of newsworthy events Brief Review of Recent Releases Web Services/Service-Oriented Architecture — You Can Do It! A look at our future direction

3 Welcome to Tenth Annual SUG
April 25 - April 29, 2004 Who would have thought next year is twentieth anniversary of Sirius Our first international User Group meeting outside of the Boston area better weather (warmer, anyway) change of scenery More new attendees More User presentations More fun!

4 Schedule Tuning - Tuesday
SOAP, UDDI, SOA, BPM, MDA, UML – Bingo! Gary Gregory HTTP Client Programming with Janus Sockets and SOAP George Walter Break Phillip Morris Object-Oriented XML API Dave Evans Lunch Janus SOAP Talks to Your End-Users Alex Kodat Managing Large Procedure Files Tom Thoresen Break RJR SOA at Centrelink Daniel Yee - Centrelink Java and Model 204: Web Serving or Application Development – It's Your Choice Steve Nelson - CCA

5 Presenting Users - Thank You!
Ann MacEwan - Texas Youth Commission Janus Web Server - Better Than Botox For Your 3270 Applications Mon Daniel Ascher - Marks and Spencer Real-Time Inventory Management Using Model 204 with Microsoft Biztalk Mon Daniel Yee - Centrelink SOA at Centrelink Tue Don Essick - Northrop Grumman Developing an Enterprise Query Solution at the DEA Wed Leon Rasheed Centrelink Centrelink Update – Managing Growth Mon Mary Brady, Sandy Kosina, Patti Neuman - CNYRIC CNYRIC Student Information System Wed

6 Presenting Partners - Thank You!
Jim Damon CCA Model 204 V6R1 – Coming Attractions Mon Pete Burlow Software Europe Sirius Wishlist Discussion Wed Robert Waggoner Nodus, Inc. Get Out the Gold Watch and the 30-year Service Pin – Retiring the KEY Attribute Wed Steve Nelson CCA Java and Model 204: Web Serving or Application Development – It's Your Choice Tue Tony Pickering Yoda Software Power Editing With Xtend Mon

7 User Language training with a Janus flair
Robert Wagonner - Nodus, Inc. User Language training with a Janus flair Packaged, on-site courses on User Language, HTML, XML and Janus Web Server Robert Waggoner Nodus, inc.P.O. Box 426 Decatur, Tx 76234

8 Xtend — PC-based Editor for UL
Tony Pickering - Yoda Software Pty Ltd Xtend — PC-based Editor for UL Syntax-aware editor for User Language integrated help UL syntax Model 204 dollar functions Sirius dollar functions and APIs Tony Pickering Yoda Software Pty Ltd PO Box 496 Leederville, Western Australia 6903 +61 [0]

9 Does Sirius need 3480 cartridge drives?
Question for the System Janitors Does Sirius need 3480 cartridge drives? We would like to retire our 3480 (18-track) drives too costly to maintain only used to distribute products "on tape" Most customers prefer download from our web site save your suggestions (ie better D/R zap UI) for Wishlist Sirius can receive 3480 or or 36 track, with or without IDRC 3490 "B model", ie 10GB or 20GB before compression Do you need to receive tapes? if so, can you accept 3490 (36-track)?

10 What do you think of Sirius' documentation?
Speaking of Feedback What do you think of Sirius' documentation? Show of hands, does anyone print the PDF's to read the manuals? We have been investing heavily in our documentation and want to make sure it is meeting your needs Jim LaPierre is our tech writer: let him know if you have any comments about font choices font size white space and binding margins anything else

11 Katie Kodat Awarded Fulbright Fellowship
The Kodats Deploy Overseas Katie Kodat Awarded Fulbright Fellowship Will be in the United Kingdom (Oxford) for 4.5 months neighbors of Matthew Webber! don't worry, we've tested our IP phone extenders Then Hungary for 6 months also has good connectivity unfortunately the wine is good too, I'm told

12 Enterprise license across all mainframes
CCA and Centrelink Sign Ten-Year Deal Enterprise license across all mainframes Reflects ongoing committment of Centrelink management to Model 204 a setback for "alternative technologies" we hope to make it a defeat of same Enabled by extraordinary pace of development for Model 204 (and related add-on products) see Jim Damon's presentation Creates new challenges and opportunities "war on MIPs" - see Leon Rasheed's presentation ultimate scalability

13 Yellow Merges with Roadway
Two largest "Less Than Truckload" (LTL) trucking companies combine Yellow buys Roadway for $1,100,000,000 Extensive evaluation of all IT to reduce duplication survival of the fittest Roadway selected for customer and partner-facing web applications Go Model 204 and Janus! primary issues time to deploy and TCO agility

14 Model 204 Rules the Roost for Massive OLAPI Database
Ultra large-scale repository continuous real-time data addition little, if any culling Complex queries accessing large volumes of data certified multi-source security filter Migrating supporting ETL/data cleansing from batch C and PL/I using VSAM staging files to native User Language takes 25% less CPU easier to maintain zero latency Yet another "modern" replacement sputters not dead yet, but bleeding profusely

15 Recent (Or Very, Very Close) Releases

16 Fast/Unload 4.1 September, 2003
Multiple output data streams for one pass of file useful for "culling" data FUEL structure enhancements labels LEAVE IF statement macro facilities for dealing with field definitions #IF <field> DEFINED #ELSE #END IF enhanced FUEL program listing Removed size limit on FUEL programs was 4MB for compiled program (Centrelink hit limit!) More #functions

17 Fast/Unload 4.2 March, 2004 Online Fast/Unload ($FUNLOAD) support for multiple output streams requires Sirius Mods 6.5 FSTATS extended to include procedure dictionary stats detailed procedure stats only if procedures are unloaded UAI now unloads UL procedures as well as data may be suppressed via the "NOPROCS" option on UAI used with Fast/Reload (in mods 6.5) to reorg procedure files can provide significant savings in compilation costs nota bene: may require more buffers for Fast/Reload step

18 Sirius Mods Version 6.5 April 31, 2004 Fast/Reload
LAI support for reloading procedures unloaded by UAI requires Fast/Unload 4.2 can automatically re-size procedure dictionary (see Tom's talk) $FUNLOAD support for multiple output streams even though Fast/Unload 4.1 introduced multiple output streams Janus Web Server performance boost when logins required SETFASTLOGIN parameter HIGHPRIORITY parameter better interfacing to RACF for authentication

19 Sirius Mods Version 6.5 April, 2004 Janus SOAP APIs
OO-style interfaces relieves argument limits on $-functions simplifies programming, improving programmer productivity Janus SOAP XPath enhancements more axes supported following-sibling, preceding-sibling, descendant-or-self, descendant ancestor-or-self, ancestor, following namespace support significant performance enhancements Janus SOAP XML conformance more syntax rules enforced for serialized XML some compatibility issues

20 Sirius Mods Version 6.5 April, 2004 Janus Sockets SirMon SirFact
support for VSE http helper wrapper dramatically reduces coding to consume Web Service - see Daniel Yee's presentation ftp support for procedure files SirMon UTI monitoring - see Leon Rasheed's presentation SirFact supports dump of $-lists associated with system objects supports display of XmlDoc, etc. contents

21 Model 204 and Janus - We Got Game
Two major developments in system architecture are playing to the strengths of Model 204 the emergence of Web Services and Service Oriented Architectures Web Services & SOA are here to stay, full stop they will become ubiquitous a renewed focus on programmer productivity, especially as it relates to application architecture epic battle is raging between IBM (with Sun on the sidelines) and Microsoft

22 Web Services Application components that can be called from anywhere across a Intra/Extra/InterNet Web Services communicate with each other via SOAP synchronous typically over HTTP asynchronous via messaging (MQ) Clients communicate to web services via XML (over HTTP) Web Services paradigm significantly better than SQL-based middleware: efficient Stored Procedure/RPC Model arguments and results not restricted to simple tables This is a standard Microsoft .NET picture and definition of Web Services. Whenever I find myself agreeing with Microsoft about something, I start to worry. That said, I believe that Web Services provide a significant advance in programming technology, finally enabling efficient distributed applications. The most important thing about Web Services is that they embrace the Stored Procedure/Remote Procedure Call model for distributed programming. The second most important thing is that the input arguments and output results from Web Services RPCs are not just simple tables, they are tree structured XML documents. Finally, because Web Services are built on XML and usually transported over HTTP, they are router friendly. Thus, it is simple for partners cooperate via Web Services.

23 Janus Web Server + Janus Sockets + Janus SOAP = Web Services
Janus APIs User Language Model 204 Janus Web Server for inbound Web Service requests HTTP(s) Janus Sockets for outbound Web Services from UL programs HTTP(S) Janus SOAP for parsing/serializing XML Websphere APIs Java or COBOL DB2 Equivalent to Websphere + DB2 + Java/COBOL (and probably CICS) but simpler This slide has a base part and then an additional build that appears on the second click. The base part shows that the combination of three Janus products: Janus Web Server, Janus Sockets and Janus SOAP allows Model 204 to participate in a Web Services architecture. Of course this requires Janus TCP/IP Base and Janus Network Security may be involved, but they are left out for simplicity. The second build makes the point that the combination of Model 204, the various Janus product APIs and User Language programs is essentially equivalent to DB2, Websphere and COBOL or Java. Of course, as anyone who remembers migrating from CICS/COBOL to Model 204 can attest, the integrated application environment provided by Model 204 and User Language is vastly more productive than a non-integrated environment like DB2 and CICS or Websphere. The simplicity of the integrated environment provided by Janus and Model 204, coupled with the high degree of automation in the Janus APIs allows Model 204 customers to rapidly embrace Web Services.

24 Web Services are Ideal for Model 204
Web Services provides excellent encapsulation internal architecture of providing server not exposed SOAP wrappers bring legacy systems into Web Services framework Number of tiers not dictated by programming paradigm strictly a function of the application Large units of work emphasize strengths of User Language Web Services allow Model 204 to participate in a level playing field with other application platforms. As was pointed out in the previous slide, Model 204 plus Janus and a User Language program is equivalent to DB2 plus Websphere and a COBOL or Java program. All that matters is that once the Web Service request is delivered, it gets processed quickly and the proper result returned. All of the details inside of the Web Service are hidden – thus it is impossible to discern a Web Service implemented in Model 204 with Janus from a Web Service implemented in another system. This architecture neutrality causes the solutions to compete on the basis of performance and time/cost to implement – both strengths of Model 204. The use of Stored Procedure/RPC lets Model 204 shine, as opposed to processing individual SQL commands transported across ODBC. As a final question, how many tiers are shown in this picture? The answer is two – the Web Service and its invoker. Although a particular Web Service might be implemented as a multi-tier solution, that decision is hidden from its caller.

25 Service-Oriented Architecture (SOA)
A way of designing applications using distributed components usually thought of as using Web Services as the components all about how to put them together see Daniel Yee's presentation For an analogy, think of the difference between designing integrated circuits and designing a PC the IC's were needed, but reusable and already existed

26 It's the Scalability, Stupid
IBM's Path to J2EE It's the Scalability, Stupid IBM's experiences with 4GL were bad Cross System Product (CSP) think IEW gone worse IBM's experiences with languages worse think PL/I and PL/S believed the problem was proprietary nature seized on Java instead (not Microsoft) IBM's path was 3GL and multi-tier CICS + COBOL + DL/1 => VSAM => DB2 always featured strong separation of logical and physical layers J2EE (n-tier) is a natural progression for IBM

27 Presentation Services
N-Tier Client/Server for Scalability Network Application Server 1 Application Load Balancing Router Application A Application B Data Server 1 Presentation Logic Presentation Services Fast Network Data Server n Router balances load between multiple application servers Backend DBMS used to hold transaction state data Addresses application server as bottleneck Even more complexity! Application Server n Application A Application B App State Data

28 Been There, Done That! 1970 - 1980 Mainframe
Data Server 1 Data Server 2 VSAM datasets DL/1 Inter-process Communications Application Server CICS Application A Application B Application A Application B Network SNA Network Thin Client 3270 Three-Tier, One Box Web architecture Browser & Java Apps Green on

29 Overwelmed CICS Programmer
CICS & 3GL (COBOL or Java) Not RAD Corporate Databases CICS App 1 3270 map sup- port DL/1 IMS VSAM DB2 Overwelmed CICS Programmer Frustrated End User CICS App 2 CICS Layers Remember this picture? end user needs application programmer can't keep up Caused by inefficiency of programming environment 3GL and tedious APIs too many moving parts and layers Complex, but Highly Evolved required for performance low level API's Many Moving Parts difficult to manage not responsive to change in spite of great tools

30 J2EE Complexity Versus Scalability
J2EE adds the standardized APIs for scalability load balancing state management etc. J2EE features formalized physical layers web server app server database J2EE makes this complexity visible to programmer just like CICSPLEX But it does provide ultimate scalability

31 Model Driven Architecture (MDA)
The IBM Solution Model Driven Architecture (MDA) Letting a programmer think at a higher level needed to address inherent complexity of CICS/J2EE don't eliminate complexity, manage it The core business of Rational Software purchased by IBM Getting a boost from open source tools May have legs increases role of "architects" not focussed at low-level details probably costs more still need programmers

32 Microsoft View of the Problem
The Microsoft view according to Bill Gates: "There is no way to make a million lines of code pretty. We need higher level approaches" Microsoft is funding an effort to merge native XML and database support into a high-level language "Programming with Circles, Triangles and Rectangles" Note the focus is on XML as having "caused" the problem Prior to Web Services, DBMS APIs were tolerated, but they were still a problem Microsoft is hedging with MDA

33 Microsoft Productivity Solution
The Microsoft view: High-level language with integrated DML facilities for DBMS and XML now, concurrency and security to follow. Sound familiar? Think Model 204 plus Janus! Are we on the right track? Microsoft far ahead of Java/J2EE for Web Services Microsoft programmer tools (VB.NET) easier to use I like our position at this point in the race

34 The Model 204 Solution The Best of Both Worlds
The productivity of a 4GL with integrated database and XML processing high-level APIs handle complexity for you Complexity of achieving scalability handled by system programmer only deals with the complexity inherent in the problem at hand High-level tools for yet more programmer productivity MDA if it pans out Avoid's Microsoft's scalability problems and IBM's complexity

35 Life is a race - our customers will be first!
Sirius Product Directions Life is a race - our customers will be first! Enhanced support for SOA SOAP/Web Services XML Schema support for Janus SOAP Janus Web Server rules for SOAP envelope processing tighter integration with MQ auto-generation of UML & WSDL from Janus SOAP UL code Single signon (Kerberos) Programmer productivity more Object-Oriented Programming features in Sirius APIs Eclipse plugins for UL generation from UML & WSDL Web services are an extremely important development that is having an instant effect upon programming architectures. As we shall see in the next slide, Web services solves the middleware problems that have stymied distributed programming efforts. The combination of Janus SOAP and Janus Web Server plus Janus Sockets gives Model 204 a strong presence in the Web Services arena. We will continue to enhance these products to make them easier to use. Programmer productivity is a very important theme for Sirius. There is widespread agreement that application platforms like J2EE (Java 2, Enterprise Edition) are just too complicated for the average programmer. With Janus and User Language we are creating a platform that is a credible and powerful, yet within the grasp of average programmers.

36 Questions?

Download ppt "Sirius Update SUG 2004 Gary Gregory."

Similar presentations

Ads by Google